📚 课程目录第2章 Kafka集群健康度巡检

2. Kafka集群健康度巡检

Kafka 集群的“健康”不是一个单点状态，而是由多层组件共同决定的复合结果。一次有效的巡检，必须同时覆盖 Broker 进程、Controller 角色、元数据协调层（ZooKeeper 或 KRaft）、磁盘、网络和 JVM 六个维度。任何一层出现劣化，都可能在数分钟到数小时内演变为分区不可用、ISR 收缩或生产端超时。本节围绕“采集什么、怎么采集、基线怎么定、告警怎么配”展开，给出可直接落地的巡检框架。

一、巡检对象与指标分层

先明确各层的职责边界，才能避免指标重复或遗漏。Broker 层关注请求处理能力与副本同步；Controller 层关注元数据变更的决策效率；ZooKeeper/KRaft 层关注元数据存储与选举稳定性；磁盘层关注容量与 I/O 延迟；网络层关注吞吐与连接质量；JVM 层关注 GC 与堆内存。六层之间存在明确的依赖方向：JVM 与磁盘是 Broker 的底层支撑，Broker 向 Controller 汇报状态，Controller 依赖 ZooKeeper/KRaft 完成选举与元数据持久化。

二、指标采集的落地方式

Kafka 原生通过 JMX 暴露指标，生产环境推荐使用 JMX Exporter 以 Java Agent 方式挂载到 Broker 进程，将指标转为 Prometheus 可抓取的格式。关键配置如下：

# 启动 Broker 时挂载 JMX Exporter
KAFKA_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=7071:/opt/jmx_exporter/kafka.yml"

# kafka.yml 关键规则示例
rules:
  - pattern: 'kafka.server<type=(Produce|Fetch)RequestMetrics, name=(TotalTimeMs|RequestsPerSec)><>(\w+)'
    name: kafka_request_$1_$2
    labels:
      quantile: "$3"
  - pattern: 'kafka.server<type=ReplicaManager, name=(\w+)><>Value'
    name: kafka_replica_$1
  - pattern: 'kafka.controller<type=KafkaController, name=(\w+)><>Value'
    name: kafka_controller_$1

磁盘与网络指标由 node_exporter 采集，重点抓取 node_filesystem_avail_bytes、node_disk_io_time_seconds_total、node_network_receive_bytes_total。ZooKeeper 使用 mntr 四字命令或 zk_exporter；KRaft 模式则直接抓取 kafka.server:type=raft-metrics 下的 current-leader、current-state、log-end-offset 等指标。

三、基线设定与告警阈值

基线不是拍脑袋定的固定值，而是基于集群正常运行时段的 P95/P99 统计。建议先采集 7～14 天数据，剔除发布窗口和已知异常时段，再按以下原则设定：

指标	正常基线（示例）	警告阈值	严重阈值
UnderReplicatedPartitions	0	>0 持续 2min	>0 持续 5min
RequestHandlerAvgIdlePercent	>0.3	<0.25 持续 5min	<0.15 持续 3min
磁盘使用率	<70%	>80%	>90%
GC 暂停 P99	<200ms	>500ms	>1s
ActiveControllerCount	1	≠1 持续 30s	≠1 持续 2min
ZK/KRaft 选举延迟	<100ms	>500ms	>2s

基线应随集群规模、硬件代际和业务峰值动态调整。新集群上线前两周建议只告警不自动处置，用于校准阈值。

四、告警配置与巡检节奏

告警规则建议按“资源层 → 服务层 → 元数据层”分级。资源层（JVM、磁盘、网络）用 Prometheus Alertmanager 直接触发；服务层（Broker 请求、副本）需结合持续时间避免抖动误报；元数据层（Controller、ZK/KRaft）一旦异常应直接升级为 P1，因为其影响面覆盖整个集群。

巡检节奏上，建议区分三种频率：实时告警覆盖 UnderReplicatedPartitions、ActiveControllerCount、磁盘使用率等硬性指标；小时级巡检检查 ISR 收缩趋势、GC 频次变化、请求延迟 P99 漂移；日级巡检输出容量增长曲线、分区分布均衡度、日志段滚动情况，用于容量规划。

常见误区：只监控 Broker 而忽略 Controller 和元数据层。实际故障中，Controller 频繁切换或 ZK 会话超时往往先于 Broker 指标劣化出现，若未覆盖这两层，会错过最佳干预窗口。

五、巡检结果判读示例

假设某次小时级巡检发现：Broker-3 的 RequestHandlerAvgIdlePercent 从 0.42 降至 0.18，同时该节点 UnderReplicatedPartitions 由 0 升至 12，磁盘写入延迟 P99 从 8ms 升至 45ms。判读路径为：先确认是否为该节点独有现象（排除集群级网络问题），再检查该节点磁盘 IOPS 是否饱和，最后核对是否有分区 leader 集中在该节点。若确认是磁盘瓶颈，应优先触发分区迁移或扩容，而非直接重启 Broker。

巡检的价值不在于采集了多少指标，而在于能否在指标劣化的早期识别出根因方向。把六层指标与基线、告警、判读路径绑定成固定动作，才能让集群健康度从“事后救火”转为“事前可控”。