1. Kafka 故障排查概述

各位好，我是老赵。做 Kafka 运维这些年，我踩过的坑比写过的代码还多。今天咱们聊聊故障排查这件事。

很多人觉得 Kafka 稳定得很，出不了大问题。嗯，这话对了一半。Kafka 确实皮实，但一旦出问题，往往就是集群级别的。我见过凌晨三点被叫起来扩容的兄弟，也见过因为一个配置项导致整个链路瘫痪的案例。

所以，咱们先把基础打牢。这一章我会带着大家回顾 Kafka 的核心架构，梳理常见的故障类型，然后给出一套我这些年沉淀下来的排查方法论和工具链。

1.1 Kafka 架构回顾

先看一张图，把 Kafka 的整体脉络理清楚。

这张图我画了很多次。每次给新人讲架构，我都会指着它说：Kafka 本质上就是一个分布式的消息队列系统。Producer 发消息，Broker 存消息，Consumer 拉消息。中间靠 ZooKeeper 管着元数据和选主。

我个人习惯把 Kafka 的架构拆成三层来看：

• 存储层：Broker 节点 + 磁盘。消息以 Segment 文件形式落盘，顺序读写是性能的关键。
• 协调层：ZooKeeper 或 KRaft（新版本）。管 Controller 选举、Topic 元数据、Consumer Group 位移。
• 客户端层：Producer 和 Consumer。这层出问题最多，我后面会重点讲。

1.2 常见故障分类

这些年我整理了一份故障清单，大概分了四大类。你想想看，是不是都遇到过？

我举个例子。有一次线上集群突然大量报错 LEADER_NOT_AVAILABLE。当时我第一反应是 Controller 挂了。查了一圈发现，其实是磁盘 IO 被打满了，导致 Leader 心跳超时，触发了频繁的选举。你看，表面是协调层的问题，根子在存储层。

1.3 故障排查方法论

排查故障，说白了就是「假设 - 验证 - 排除」的循环。我总结了一套五步法，分享给大家。

1. 明确现象：用户报什么错？监控告警是什么？先搞清楚「发生了什么」。
2. 收集信息：日志、监控指标、线程栈、网络抓包。信息越全，定位越快。
3. 提出假设：根据现象和信息，列出可能的原因。比如「可能是磁盘满了」「可能是 GC 导致停顿」。
4. 验证假设：用工具或命令去验证。比如 df -h 看磁盘，jstat 看 GC。
5. 定位根因：排除掉错误的假设，找到真正的根因。然后修复、验证、复盘。

这套方法看起来简单，但很多人一着急就跳步骤。我记得有一次，一个同事看到 Consumer Lag 很高，直接去调 max.poll.records，结果越调越糟。其实根因是 Broker 端磁盘 IO 瓶颈，调客户端参数根本没用。

1.4 工具链

工欲善其事，必先利其器。我平时排查故障，离不开下面这些工具。我把它们分成三类。

命令行工具

• kafka-topics.sh：查看 Topic 详情、分区分布、ISR 状态。
• kafka-consumer-groups.sh：查看 Consumer Group 位移和 Lag。
• kafka-log-dirs.sh：查看各 Broker 磁盘使用情况和日志文件状态。
• kafka-reassign-partitions.sh：分区迁移和重新平衡。

监控与诊断

• JMX 指标：Kafka 暴露了大量 JMX 指标，比如 kafka.server:type=BrokerTopicMetrics。我习惯用 Prometheus + Grafana 采集和展示。
• jstack / jmap：看线程栈和堆内存。遇到 CPU 飙高或 OOM，这两个命令是救命稻草。
• tcpdump / netstat：网络问题排查利器。比如客户端连不上，抓包一看，哦，防火墙把端口封了。

日志分析

• server.log：Broker 运行日志，记录了所有关键事件，比如 Leader 选举、异常关闭。
• controller.log：Controller 的专属日志。如果集群出现频繁的 Leader 变更，这里一定有线索。
• kafka-request.log：慢请求日志。打开这个，能抓到那些处理时间超过阈值的请求。

好了，这一章的内容就到这里。架构、故障分类、方法论、工具链，这四个东西是后面所有章节的基础。你把这些吃透了，后面的实战案例才能听得明白。