情况分析
客户端异常报警
晚上10点20分接到使用方电话,日志持续报以下异常,持续时间已有10多分钟。
1 | ERROR 2019-05-15 23:05:23,221 [kafka-producer-network-thread | producer-1] A failure occurred sending a message to Kafka. |
集群状况查看
监控及Kafka Manager显示节点数量正常。问题集群有6个节点,3个副本。查看日志发现,都在大量输出选举的日志,日志中暂时没有发现明显的ERROR和FATAL日志。类似内容如下:
1 | [2019-05-15 22:03:49,511] INFO Rolled new log segment for 'order-KSTREAM-AGGREGATE-STATE-STORE-0000000002-repartition-196' in 1 ms. (kafka.log.Log) |
GC日志查看
通过查看各个节点GC日志发现,其中一台节点GC回收异常,堆内存回后,只能回收600来M的空间。应该可以初步确定为问题节点。
日志内容如下:
1 | 2019-05-15T23:51:14.885+0800: 21994518.023: [GC pause (G1 Evacuation Pause) (young), 0.0749305 secs] |
故障恢复
问题节点下线
确定为问题节点后,先将该节点下线。由于三个副本,所以对可用性不能造成影响。在该节点下线后,客户端报警解除,恢复正常。
问题节点恢复
问题节点为正常下线(kill -s TERM), 当时在恢复过程中出现卡顿,其中一个分区卡顿长达20多分钟没有继续往下走。
尝试将该问题分区移除日志目录,重新启动,该topic又出现了其他问题的卡顿。索性将该topic的所有分区全部移除日志目录。但是依然有其他topic的分区卡顿不前,在反复近10次重启后,依然没有恢复该节点。最后使用空目录启动,节点恢复。
问题复盘
有几个问题需要澄清
1 | 1.配置了GC回收短信告警,而告警没有发出 |
查看问题节点server日志
发现Unable to reconnect to ZooKeeper service出现频率非常高,没隔1到2分钟就会打印一次。
1 | [2019-05-15 22:20:14,397] INFO Opening socket connection to server 192.168.x.x/192.168.x.x2181. Will not attempt to authenticate using SASL (unknown error) (org.apache.zookeeper.ClientCnxn) |
查看zk日志
1 | 2019-05-15 22:49:58,992 [myid:3] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@942] - Client attempting to establish new session at /192.168.x.x:20482 |
查看GC日志
1 | 2019-05-15T22:25:59.422+0800: 21989402.560: [Full GC (Allocation Failure) 8071M->4285M(8192M), 10.3987109 secs] |
备注:频繁Full GC, 间隔在1到2分钟,每次Full GC的时间长达10秒以上。查看server和zk日志,发现问题节点在频繁的连接zk,导致partition leader的频繁选举。
监控查看
问题节点堆内存和老年代回收居高不下
回收时间和回收次数明显增加
网络空闲率显著高于其他节点
问题节点在三天前堆内存和老年代使用开始陡增
复盘总结
由于堆内存不能正常回收,导致频繁(1到2分钟)的Full GC.
每次Full GC长达10秒以上,导致连接zk的session过期(默认6秒)
Session的过期导致问题节点频繁重连zk集群,造成频繁Partition Leader选举
未尽事项
由于未dump当时的堆照,分析堆内存异常原因比较困难,如果调查三天来有哪些业务使用造成的,也比较困难。
恢复GC短信告警,发生时问题时告警短信异常。
除了增加GC回收告警外,增加Full GC告警