这是《Kafka 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Kafka 集群的稳定性 = 指标 + 告警 + 定期演练。本章给出指标体系、部署方案与阈值建议，让问题在用户感知前被发现。
19.1 监控什么
五个层面：
| 层面 | 关注点 |
|---|---|
| Broker | 存活、请求延迟、线程池、磁盘、网络 |
| 分区/副本 | ISR 健康、Leader 均衡、离线分区 |
| Controller/KRaft | 仲裁状态、元数据滞后 |
| 消费组 | lag、rebalance 次数、处理耗时 |
| 主机 | CPU、内存、页缓存、磁盘 IO、网络、时钟 |
19.2 Broker 关键指标
| 指标 | 含义 | 告警建议 |
|---|---|---|
ActiveControllerCount |
活跃 Controller 数 | !=1 立即告警 |
OfflinePartitionsCount |
无 Leader 分区数 | >0 严重告警 |
UnderReplicatedPartitions |
ISR 不足的分区数 | >0 持续 5 分钟告警 |
UnderMinIsrPartitionCount |
低于 min ISR 的分区 | 严重告警（影响写入） |
RequestHandlerAvgIdlePercent |
IO 线程空闲率 | <0.3 关注 |
NetworkProcessorAvgIdlePercent |
网络线程空闲率 | <0.3 关注 |
BytesInPerSec / BytesOutPerSec |
流量 | 突增突降告警 |
MessagesInPerSec |
消息速率 | 趋势监控 |
RequestLatencyAvg/Max |
请求延迟 | 按 P99 阈值 |
LogDirSize / 磁盘使用率 |
容量 | >80% 告警，>90% 严重 |
IsrShrinksPerSec / Expands |
ISR 变化频率 | 频繁收缩告警 |
JMX 名称示例（Broker 端）：
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent
kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
19.3 消费者与 Lag 监控
Lag 是业务最敏感的指标：
lag = log_end_offset - committed_offset
三种采集方式：
- 客户端指标：消费者进程暴露
records-lag-max（准确、实时，但消费者挂了就没有数据）； - Burrow / kafka-lag-exporter：外部独立采集，覆盖消费者已宕机的场景，推荐；
- 命令行巡检：
kafka-consumer-groups.sh --describe，适合兜底脚本。
告警不要只看绝对值。同样 100 万 lag：
- 每秒消费 50 万的组：2 秒追平，正常；
- 每秒消费 100 的组：2.7 小时，严重。
推荐同时监控 lag 趋势（是否持续增长） 与 追平时间估算（lag / 消费速率）。
19.4 用 Prometheus + Grafana 搭建
启用 JMX
export JMX_PORT=9999
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote=true \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"
bin/kafka-server-start.sh config/server.properties
JMX Exporter 配置（片段）
startDelaySeconds: 10
hostPort: 127.0.0.1:9999
rules:
- pattern: "kafka.server<type=(.+), name=(.+)><>Value"
name: kafka_server_$1_$2
type: GAUGE
- pattern: "kafka.network<type=(.+), name=(.+)><>Value"
name: kafka_network_$1_$2
type: GAUGE
采集与服务发现
scrape_configs:
- job_name: kafka-jmx
static_configs:
- targets:
- broker1:7071
- broker2:7071
- broker3:7071
- job_name: kafka-lag
static_configs:
- targets: ['lag-exporter:8080']
Grafana 社区有现成 Kafka 面板（搜索 “Kafka Exporter” / “Kafka JMX”），建议至少包含四块：
- 集群健康：Controller、离线分区、ISR；
- 流量：BytesIn/Out、MessagesIn 按 Broker/Topic；
- 延迟与线程：RequestLatency、Idle Percent；
- 消费：lag 趋势、追平时间、rebalance 频率。
19.5 告警策略建议
| 级别 | 条件示例 |
|---|---|
| P0 | OfflinePartitionsCount > 0；ActiveControllerCount != 1；磁盘 > 90%；Broker down |
| P1 | UnderReplicated 持续 > 5min；UnderMinIsr > 0；lag 追平时间 > 30min |
| P2 | 磁盘 > 80%；请求 P99 翻倍；ISR 频繁抖动；rebalance 频率异常 |
| 提醒 | 流量异常波动；topic 增长异常；配置变更事件 |
告警原则：
- 每条告警都要有明确的处置动作（runbook 链接）；
- 抑制抖动（持续 N 分钟才触发）；
- 分级通知，避免“告警疲劳”后大家集体屏蔽。
19.6 日志与事件
除了指标，还要保留：
server.log/controller.log：切主、分区迁移、副本剔除；- 客户端日志：rebalance、超时、重试；
- 审计事件：topic/ACL 配置变更（谁在什么时候改了什么）；
kafka-configs.sh --describe --all定期快照，用于配置漂移对比。
19.7 巡检脚本示例
#!/usr/bin/env bash
BS=localhost:9092
echo "== 集群描述 =="
bin/kafka-metadata-quorum.sh --bootstrap-server $BS describe --status
echo "== 离线/落后分区 =="
bin/kafka-topics.sh --bootstrap-server $BS --describe --unavailable-partitions
bin/kafka-topics.sh --bootstrap-server $BS --describe --under-replicated-partitions
echo "== 消费组 lag =="
bin/kafka-consumer-groups.sh --bootstrap-server $BS --list | while read g; do
bin/kafka-consumer-groups.sh --bootstrap-server $BS --describe --group "$g" |
awk -v g="$g" 'NR>1 && $NF ~ /^[0-9]+$/ { if ($NF > 100000) print g, $1, $2, "lag="$NF }'
done
定时执行并输出到群机器人，就是最朴素的“可观测性兜底”。
本章小结
- 监控覆盖 Broker、分区副本、Controller、消费组、主机五层；
UnderReplicated / Offline / Controller / Disk / Lag是五大生命线；- lag 告警看趋势与追平时间，不只看绝对值；
- Prometheus + Grafana + lag-exporter 是标准组合；
- 每条告警配套 runbook，否则只是噪音。
思考题
- 为什么消费者自带 lag 指标还不够，需要外部 lag 采集器？
- 磁盘使用率告警应该设几级？每级对应的动作是什么？
- 如果只能保留 5 个 Kafka 指标，你选哪 5 个？为什么？