Kafka 集群部署环境
1、kafka 集群所用版本 0.9.0.1
2、集群部署了实时监控: 通过实时写入数据来监控集群的可用性, 延迟等 ;
Part 1
1 集群故障发生
-
集群的实时监控发出一条写入数据失败的报警, 然后马上又收到了恢复的报警, 这个报警当时没有重要, 没有去到对应的服务器上去看下 log, 恶梦的开始啊~~~
-
很快多个业务反馈 Topic 无法写入, 运维人员介入
2 故障解决
- 运维人员首先查看 kafka broker 日志, 发现大量如下的日志:
- 这个问题就很明了了, 在之前的文章里有过介绍: Kafka 运维填坑, 上面也给出了简单修复, 主要原因是 新版 kafka 客户端 sdk 访问较旧版的 kafka, 发送了旧版 kafka broker 不支持的 request, 这会导致 exception 发生, 然后同批次 select 出来的所有客户端对应的 request 都将被抛弃不能处理, 代码在 SocketServer.scala 里面, 大家有兴趣可以自行查阅
1. 这个问题不仅可能导致客户端的 request 丢失, broker 和 broker, broker 和 controller 之间的通讯也受影响；’
2. 这也解释了为什么 实时监控 先报警 然后又马上恢复了: 不和这样不被支持的 request 同批次处理就不会出现问题；
- 解决过程:
我们之前已经修复过这个问题, 有准备好的相应的 jar 包 ;
运维小伙伴开始了愉快的 jar 包替换和启动 broker 的工作~~~~~~
3 集群恢复
-
kafka broker 的优雅 shutdown 的时间极不受控, 如果强行 kill -9 在 start 后要作长时间的 recovery, 数据多的情况下能让你等到崩溃；
-
集群重启完, 通过 log 观察, ArrayIndexOutOfBoundsException 异常已经被正确处理, 也找到了相应的业务来源；
-
业务反馈 Topic 可以重新写入；
然而, 事件并没有结束, 而是另一个恶梦的开始
Part 2
1 集群故障再次发生
- 很多业务反馈使用原有的 group 无法消费 Topic 数据 ;
- 用自己的 consumer 测试, 发现确实有些 group 可以, 有些 group 不能消费 ;
- 一波不平一波又起, 注定是个不平凡的夜晚啊, 居然还有点小兴奋~~~
2 故障解决
- 查看 consumer 测试程序不能消费时的日志, 一直在重复如下 log:
1. 第一条日志 说明 consumer 已经确认了当前的 coordinator, 连接没有问题 ;
2. 第二条日志显示没有 Not coordinator, 对应 broker 端是说虽然 coordinator 确认了, 但是没有在这个 coodinator 上找到这个 group 对应的 metada 信息 ;
3.group 的 metada 信息在 coordinator 启动或 __consuser_offsets 的 partion 切主时被加载到内存, 这么说来是相应的 __consumer_offsets 的 partition 没有被加载 ;
4. 关于 coordinator, __consumer_offsets, group metada 的信息可以参考 Kafka 的消息是如何被消费的?
- 查看 broker 端日志, 确认 goroup metadata 的相关问题
1. 查找对应的 __consumer_offsets 的 partition 的加载情况, 发现对应的
2. 没有找到下面类似的加载完成的日志:
也没有发生任何的 exception 的日志
3. 使用 jstack 来 dump 出当前的线程堆栈多次查看, 证实一直是在加载数据, 没有卡死 ;
现在的问题基本上明确了, 有些 __consumer_offsets 加载完成了, 可以消费, 些没有完成则暂时无法消费, 如果死等 loading 完成, 集群的消费可以正常, 但将花费很多时间 ;
- 为何 loading 这些 __consumer_offsets 要花费如此长的时间?
1. 去到 __conuser_offsets partition 相应的磁盘目录查看, 发生有 2000 多个 log 文件, 每个在 100M 左右 ;
2.kaka 的 log compac 功能失效了, 这个问题在之前的文章里有过介绍: Kafka 运维填坑,
3.log compact 相关介绍可以参考 Kafka 的日志清理 -LogCleaner
- 手动加速 Loading:
即使 log cleaner 功能失败, 为了加速 loading, 我们手动删除了大部分的 log 文件 ; 这样作有一定风险, 可能会导致某些 group 的 group metadata 和 committed offset 丢失, 从而触发客户端在消费时 offset reset;
3 故障恢复
- 所有 __consumer_offset 都加载完后, 所有 group 均恢复了消费 ;
总结
- 对实时监控的报警一定要足够重视 ;
- 更新完 jar 包, 重启 broker 时, 三台存储 __consumer_offsets partition 合部同时重启, 均在 Loading 状态, 这种作法不合适, 最多同时重启两台, 留一台可以继续提供 coordinattor 的功能 ;
- 加强对 log compact 失效的监控, 完美方案是找到失效的根本原因并修复 ;
本文转载自公众号 360 云计算（ID：hulktalk）。
原文链接：
评论