elk生产问题之kafka问题记录

 

今天经同事反馈，日志云有日志缺失，于是从源头开始查

1、首先查看原始日志，发现原始日志正常在刷

2、查看filebeat日志，发现连接kafka异常

3、登录kafka manager页面查看，发现确实有个6个broker掉了两个

4、猜测是full gc ，查看kafka日志后发现确实如此

cat  kafkaServer-gc.log.4.current|grep -E 2021-03-03T|grep "Full GC"|tail -10

5、先把问题解决、重启kafka节点，但是在时报错Attempt to append an offset (110756715) to position 40111 no larger than the last offset appended (110756715)

这个问题是因为不同kafka节点数据不一致造成的，手动清空报错的目录，然后再次重启

问题暂时解决!

 

后续:查看kafka的查看启动配置文件，发现堆内存配置为32G，这个值超过了推荐的最大值31G，会导致指针压缩失效的问题，初步猜测full gc与此相关，经讨论后将堆内存改为26G，设想是增加年轻代的回收频率

export KAFKA_HEAP_OPTS = "-Xmx26G -Xms26g"

暂时未出现Full GC ，同时为了以后第一时间响应，添加了Full GC的关键字告警，但是我总有隐隐的担忧，原因是所有机器其实都是32G的配置，为什么只有这台告警，因为还有其他事要忙，就先搁置了

过了一个星期，果然又出现了Full GC关键字告警，这次我们决定一定要把根因找出来，和开发讨论，开发建议把堆内存转储文件导出来，通过jmap命令

jmap -dump:format=b,file=/applog/kafka-gc-20210303.log 38274

文件大小达到13个G！查看这个文件也是一波三折，期间想通过sz命令下载到本机，但是限速200k/s，后面又想用jhat在服务器上看，结果cpu内存直接飙升，怕引起生产告警，马上kill了，最后通过临时的python web服务>压缩>ftp，才导出来

导出来后，想通过visualvm打开，结果软件又卡死了，最后是通过eclipse出品的mat工具分析，输出了分析报告

将报告发给厂商支持人员分析，后续待补充