3、Kafka集群运维与监控：Broker状态、Topic分区、消费者Lag、磁盘与网络IO

Kafka 在实时数仓里是什么角色？说白了，它就是整个数据管道的大动脉。所有实时数据都得从它这儿过，一旦它出问题，下游的 Flink、ClickHouse 全得断粮。我这些年跟 Kafka 集群打交道，踩过的坑比吃过的盐还多。今天咱们就把 Broker 状态、Topic 分区、消费者 Lag、磁盘和网络 IO 这几个核心监控点，一个一个捋清楚。

3.1 Broker 状态监控：集群的「心跳」

Broker 是 Kafka 集群的节点，它的状态直接决定了集群的可用性。我习惯把 Broker 监控分成三层：存活检测、Controller 状态、以及 JMX 指标采集。

3.1.1 存活检测

最简单的办法就是看 Zookeeper 的 /brokers/ids 节点。每个 Broker 启动时会在这里注册一个临时节点，一旦宕机，节点自动消失。

# 查看当前所有在线 Broker
./zookeeper-shell.sh localhost:2181 ls /brokers/ids

# 查看某个 Broker 的详细信息
./zookeeper-shell.sh localhost:2181 get /brokers/ids/1

不过光靠 ZK 不够。我记得有一次，Broker 进程还在，但已经假死了——不处理请求，不响应心跳。ZK 那边显示在线，实际已经废了。所以，我建议额外做一层端口探测或 Kafka 原生 API 检测。

3.1.2 Controller 状态

Controller 是集群的「大脑」，负责分区 Leader 选举和元数据管理。Controller 挂了，整个集群的元数据操作都会卡住。

监控 Controller 的核心指标：

• ActiveControllerCount：正常值为 1，大于 1 说明脑裂了，小于 1 说明没有 Controller。
• ControllerElectionRate：选举频率。短时间内频繁选举，说明集群不稳定。

我曾经遇到过一个场景，网络抖动导致 Controller 频繁重选，每次重选都要重新分配 Leader，结果整个集群的写入延迟飙升了 10 倍。排查了半天，最后发现是交换机端口协商出了问题。

3.1.3 JMX 关键指标

Kafka 的 JMX 指标非常丰富，但别全采，挑几个关键的就行：

指标名称	MBean 路径	告警阈值
请求处理线程空闲率	kafka.network:type=RequestChannel,name=RequestQueueSize	队列大小持续 > 1000
消息入站速率	kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec	与基线偏差 > 50%
分区 Leader 数量	kafka.controller:type=KafkaController,name=LeaderCount	单 Broker 负载不均

3.2 Topic 分区监控：数据的「车道」

Topic 分区是 Kafka 并行处理的基本单位。分区出了问题，数据要么写不进去，要么读不出来。

3.2.1 分区状态与 ISR

每个分区有多个副本，其中一个是 Leader，其余是 Follower。ISR（In-Sync Replicas）是跟 Leader 保持同步的副本列表。

监控重点：

• UnderReplicatedPartitions：副本数小于配置的复制因子。这是最危险的信号，说明数据有丢失风险。
• OfflinePartitions：分区没有 Leader。这意味着该分区完全不可用。

我记得有一次，一个 Broker 磁盘满了，导致它上面的分区副本全部掉出 ISR。结果那个 Topic 的写入延迟从 5ms 飙到了 2 秒。清理磁盘后，ISR 自动恢复，但花了将近 10 分钟才追上数据。

3.2.2 分区 Leader 均衡

理想情况下，Leader 应该均匀分布在所有 Broker 上。但现实往往不是这样。我见过一个集群，80% 的 Leader 集中在两台 Broker 上，其他 Broker 几乎闲置。

怎么检查？

# 查看每个 Broker 上的 Leader 分布
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions

# 手动触发 Leader 重均衡
kafka-leader-election.sh --bootstrap-server localhost:9092 --election-type preferred --all-topic-partitions

3.2.3 分区数量监控

分区不是越多越好。每个分区对应一个日志目录和一组文件句柄。分区太多，Broker 的内存和文件句柄都会被耗尽。

我一般建议：

• 单 Broker 分区数不超过 2000（机械盘）或 4000（SSD）
• 单 Topic 分区数不超过 100（除非有特殊需求）
• 监控 kafka.server:type=BrokerTopicMetrics,name=TotalPartitionCount

3.3 消费者 Lag 监控：数据管道的「堵点」

消费者 Lag 是实时数仓最核心的监控指标之一。它直接反映了数据从 Kafka 到下游系统的延迟。

3.3.1 Lag 的计算方式

Lag = 生产者的最新偏移量 - 消费者的当前偏移量。说白了，就是消费者落后了多少条消息。

# 查看消费者组 Lag
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group my-group --describe

输出示例：

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
my-group        order_topic     0          1500            2000            500
my-group        order_topic     1          1200            2000            800

3.3.2 Lag 的告警策略

Lag 不是越小越好，也不是有 Lag 就要告警。关键看趋势：

• 持续增长：消费者处理能力跟不上生产速度，需要扩容或优化。
• 突然飙升：消费者挂了，或者下游系统（如 Flink、ClickHouse）出现瓶颈。
• 波动正常：偶尔的 Lag 波动是正常的，比如 GC 暂停、网络抖动。

3.3.3 消费者 Rebalance 监控

Rebalance 是消费者组的「重新洗牌」。每次 Rebalance 都会暂停消费，导致 Lag 瞬间上涨。

监控指标：

• Rebalance 次数：短时间内频繁 Rebalance，说明消费者不稳定。
• Rebalance 耗时：超过 30 秒的 Rebalance 需要关注。

我曾经遇到过一个坑：某个消费者因为处理逻辑太慢，导致心跳超时，被踢出消费者组。然后它又自动加入，触发 Rebalance。结果就是「加入 → 超时 → 踢出 → 再加入」的死循环，Lag 从 1000 涨到了 10 万。最后排查发现是下游数据库连接池满了，导致消费线程阻塞。

3.4 磁盘与网络 IO 监控：硬件的「红线」

Kafka 是 IO 密集型应用，磁盘和网络就是它的命门。这两个指标一旦出问题，整个集群的性能都会崩。

3.4.1 磁盘监控

Kafka 的数据是顺序写入磁盘的，但顺序写不代表磁盘不会出问题。

核心指标：

• 磁盘使用率：超过 85% 就要告警。超过 90%，Kafka 可能会自动停止写入。
• 磁盘 IO 等待时间（await）：正常值 < 10ms，超过 50ms 说明磁盘有瓶颈。
• 磁盘吞吐量（r/s, w/s）：与硬件规格对比，看是否达到上限。

# 查看磁盘 IO 状态
iostat -x 1 5

# 查看 Kafka 日志目录大小
du -sh /data/kafka/logs/*

3.4.2 网络监控

网络是 Kafka 的另一个瓶颈。尤其是跨机房、跨可用区的部署，网络延迟和带宽限制会直接影响吞吐量。

监控重点：

• 网络吞吐量（BytesInPerSec, BytesOutPerSec）：与网卡带宽对比，看是否接近上限。
• 网络重传率：重传率 > 1% 说明网络质量有问题。
• TCP 连接数：每个消费者和生产者都会建立 TCP 连接，连接数太多会耗尽 Broker 的资源。

我记得有一次，业务方突然反馈数据延迟很大。我一看网络监控，发现 BytesOutPerSec 已经达到了 900 Mbps，而网卡是千兆的。说白了，网卡被打满了。后来加了万兆网卡，问题解决。

3.4.3 磁盘与网络的联动分析

很多时候，磁盘和网络的问题是相互影响的。比如：

• 网络带宽不足 → 数据堆积在 Broker 内存 → 内存不够 → 刷盘频率增加 → 磁盘 IO 飙升
• 磁盘 IO 慢 → 数据写入慢 → 生产者积压 → 网络吞吐量下降

所以，我建议把磁盘和网络指标放在同一个监控大盘上，方便联动分析。