Kafka集群故障分析

举报
寒衣 发表于 2026/09/20 22:42:28 2026/09/20
【摘要】 kafka报错Timed out: probably due to broker version < 0.10 (after 10007ms, timeout #0)

Kafka集群故障分析

📋 报告概述

项目 内容
故障发生时间 11:20:24 ~ 11:20:42
故障恢复时间 11:20:42(自动恢复)
影响时长 17.3 秒(Full GC暂停)+ 客户端超时叠加
影响范围 连接到受影响Broker(ID=3,xx.xx.xx.xx:21007)的所有客户端
故障等级 P1(核心服务受损)
根因状态 ✅ 已定位 ✅已修复

1. 故障现象

1.1 客户端报错

Kafka客户端(librdkafka)在 11:20:34 ~ 11:20:39 集中出现以下报错:

[11:20:39][SfServer][WARN] rdkafka#producer-11: 
sasl_plaintext://21007/3: ApiVersionRequest failed: 
Local: Timed out: probably due to broker version < 0.10 
(after 10007ms, timeout #0)

[11:20:39][SfServer][WARN] rdkafka#producer-15: 
sasl_plaintext://21007/3: ApiVersionRequest failed: 
Local: Timed out: probably due to broker version < 0.10 
(after 10007ms, timeout #0)

关键信息

  • 报错指向 Broker ID = 3xx.xx.xx.xx:21007
  • 超时时间为 10007msapi.version.request.timeout.ms 默认值 10 秒)
  • 报错描述具有误导性(“probably due to broker version”),实际与版本无关

1.2 业务影响

指标 表现
生产者发送成功率 短时间内下降,超时期间写入失败
消息延迟 部分消息延迟增加(客户端自动重试后恢复)
服务可用性 约 17 秒内该 Broker 不可用,影响其 Leader 分区的读写

2. 排查过程

2.1 初步排查

排查项 结果 结论
客户端配置是否变更 未变更 排除配置错误
故障是否必现 偶发 排除版本硬性不兼容
是否有Broker版本变更 排除升级导致的问题

2.2 网络层排查

2.2.1 系统流量监控

Broker 3(xx.xx.xx.xx)的网卡流量进行分析:

时间段 service-bond4 吞吐量(txkB/s) 状态
10:00 ~ 11:00 ~16,000 kB/s ✅ 正常
11:10 ~ 11:20 ~3,000 ~ 4,200 kB/s ❌ 断崖下跌(正常 20%)
11:30 ~7,500 kB/s 🔄 恢复至 50%
11:40+ ~16,600 kB/s ✅ 恢复正常

关键发现rxpck/stxpck/s 同时、同比例下跌,说明数据包在应用层未被处理,而非网络链路故障。

2.2.2 硬件/链路层排查

排查项 结果
Bonding 状态(/proc/net/bonding/service-bond4 ✅ 双链路 up,LACP 协商正常
内核网卡错误日志(dmesg ✅ 无 link down/up 记录
交换机告警日志 ✅ 无异常记录
多台服务器流量对比 三台 Kafka 服务器全部同时出现相同断崖

结论:排除网络层故障,故障源在应用层(JVM)。

2.3 JVM/GC 层排查(根因定位)

查看 Broker 3 的 GC 日志(/var/log/Bigdata/kafka/broker/kafkaServer-*-gc.log):

关键日志

[2026-xx-xxT11:19:13.267+0300] GC(25741) Pause Young (Normal) (G1 Evacuation Pause) 
18739M->355M(30720M) 22.643ms

[2026-xx-xxT11:20:24.960+0300] GC(25742) Pause Full (System.gc())   ←  致命触发点

[2026-xx-xxT11:20:42.295+0300] GC(25742) Total 566211353 16556478064
[2026-xx-xxT11:20:42.295+0300] GC(25742) Class Histogram (before full gc) 17368.756ms

[2026-xx-xxT11:20:42.329+0300] GC(25742) Class Histogram (before full gc) 17368.756ms
[2026-xx-xxT11:20:42.559+0300] GC(25742) Phase 1: Mark live objects 228.436ms
[2026-xx-xxT11:20:42.583+0300] GC(25742) Phase 2: Prepare compaction 24.184ms
[2026-xx-xxT11:20:42.655+0300] GC(25742) Phase 3: Adjust pointers 71.988ms
[2026-xx-xxT11:20:42.666+0300] GC(25742) Phase 4: Compact heap 10.678ms
[2026-xx-xxT11:20:42.736+0300] GC(25742) Metaspace: 91942K(92928K)->91942K(92928K)

2.4 启动参数确认

-Xmx30G -Xms30G -XX:+UseG1GC -XX:+ExitOnOutOfMemoryError 
-XX:ReservedCodeCacheSize=512m -XX:InitialCodeCacheSize=256m

问题:当前 JVM 参数中 未包含 -XX:+DisableExplicitGC,无法阻止 System.gc() 调用。

3. 根因分析

3.1 根因结论

本次故障的根本原因是 Broker 进程因代码中主动调用 System.gc(),触发了长达 17.3 秒的 Full GC(Stop-The-World 暂停),导致 Broker 在此期间完全无法处理任何网络请求。

3.2 根因证据链

证据 来源 结论
GC 日志显示 Pause Full (System.gc()) GC 日志 代码显式调用触发
STW 暂停持续 17368ms GC 日志 17.3 秒完全无响应
网卡 rx/tx 同时断崖 sar -n DEV 应用层阻塞导致
客户端超时 10007ms 客户端日志 落在 GC 窗口内
多台服务器同时断崖 sar -n DEV 共享依赖(认证服务)或各自 GC
交换机无告警、Bonding 正常 硬件排查 排除物理网络故障

3.3 报错信息来源

librdkafka 的 ApiVersionRequest 是客户端与 Broker 建立连接后的第一个请求。当该请求因网络超时失败时,librdkafka 的默认错误消息会提示 “probably due to broker version < 0.10”,这是由于早期版本不支持该协议。本次故障中,超时的真正原因是 Broker 因 GC 无响应,而非版本不兼容。

4. 时序图

5. 解决方案

5.1 立即措施

禁止代码中显式调用 System.gc()

在 Kafka Broker 的 JVM 启动参数中添加:

-XX:+DisableExplicitGC

FusionInsight 环境操作步骤

  1. 登录 FusionInsight Manager 管理界面
  2. 进入 集群 > Kafka > 配置 > 全部配置
  3. 搜索 KAFKA_JVM_PERFORMANCE_OPTSGC_OPTS
  4. 在当前 JVM 参数末尾追加:
    -XX:+DisableExplicitGC
    
  5. 保存配置,按提示滚动重启所有 Broker 节点
  6. 验证参数生效:
    ps -ef | grep kafka | grep DisableExplicitGC
    

6. 附录

6.1 时间线汇总

时间 事件 状态
11:19:13.267 Minor GC 正常执行(22ms) 🟢 正常
11:20:24.960 Full GC 触发(System.gc()) 🔴 故障起点
11:20:24.960 ~ 11:20:42.295 Stop-The-World 暂停(17.3秒) 🔴 故障
11:20:34 ~ 11:20:39 客户端超时报错集中爆发 🔴 故障
11:20:39 网卡流量跌至谷底 🔴 故障
11:20:42.295 Full GC 结束 🟢 恢复起点
11:20:42.736 GC 收尾完成,业务恢复 🟢 恢复
11:30 流量恢复至 50% 🟢 恢复
11:40 流量完全恢复 ✅ 正常

7. 结论

本次故障的根本原因是 Broker JVM 因代码中主动调用 System.gc() 触发 Full GC,导致长达 17.3 秒的 Stop-The-World 暂停,而非网络或配置问题。通过在 JVM 参数中添加 -XX:+DisableExplicitGC 可从根本上解决此问题。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。