监控
定义与作用
Kafka 监控回答四个核心问题：集群健康吗？生产者正常吗？消费者追上了吗？磁盘还够吗？ Kafka 通过 JMX（Java Management Extensions）暴露了数百个指标，本节聚焦于生产环境最关键的那 20 个。
核心原理
监控四象限
关键指标速查
| 类别 | JMX Metric | 告警阈值 | 含义 |
|---|---|---|---|
| 可靠性 | UnderReplicatedPartitions | > 0 | 有分区副本不足 |
| 可靠性 | OfflinePartitionsCount | > 0 | 有分区无 Leader（不可读写） |
| 可靠性 | ActiveControllerCount | ≠ 1 | Controller 异常（0：无，2+：脑裂） |
| 吞吐 | BytesInPerSec | 相比基线下降 50% | 写入吞吐骤降 |
| 吞吐 | BytesOutPerSec | 相比基线下降 50% | 读取吞吐骤降 |
| 延迟 | TotalTimeMs P99 | > 100ms | 请求延迟升高 |
| 延迟 | RequestQueueSize | > 1000 | 请求积压 |
| 消费 | RecordsLagMax | > 100000 | 消费严重滞后 |
| 磁盘 | 磁盘使用率 | > 80% | 磁盘即将写满 |
| GC | jvm.gc.time | > 500ms/min | GC 频率过高 |
完整示例
示例一：JMX 指标采集
# 启动 Kafka 时开启 JMX
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9999 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"
bin/kafka-server-start.sh config/kraft/server.properties
# 用 JConsole 连接查看
jconsole localhost:9999
示例二：命令行动态监控
# 消费组 Lag 检查（建议加入 Cron）
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--group order-processor --describe | awk '{if ($6 > 10000) print "CRITICAL: " $2 " LAG=" $6}'
# 未完全同步的分区
bin/kafka-topics.sh --describe --under-replicated-partitions \
--bootstrap-server localhost:9092
# Broker 日志检查
grep -i "error\|warn" /opt/kafka/logs/server.log | tail -20
易错场景
易错 1：只看平均值不看 P99
场景：监控仪表盘显示 TotalTimeMs 平均 5ms，看起来正常。
事实：P99 可能是 500ms。长尾延迟才是用户体验的真实反映。
正确做法：监控 P50、P99、P999 三个分位数。
易错 2：忽视 UnderReplicatedPartitions 的瞬时尖峰
场景：滚动重启一个 Broker，UnderReplicatedPartitions 短暂 > 0 但不告警。
事实：滚动重启会导致大量分区暂缺副本，这是正常行为。但如果在非计划内（没有运维操作）时出现 → 真正的故障。
正确做法：告警时区分"瞬时尖峰"和"持续异常"。持续超过 5 分钟的 UnderReplicatedPartitions > 0 才告警。
面试高频考点
Q：如何判断 Kafka 集群是否"健康"？核心看哪 5 个指标？
A：
UnderReplicatedPartitions— 值为 0：所有分区都有足够副本ActiveControllerCount— 值为 1：Controller 正常工作OfflinePartitionsCount— 值为 0：所有分区都可读写- Consumer Group Lag — 不超过业务阈值：消费者不堆积
- 磁盘使用率 — < 80%：不会因磁盘满停机
这 5 个指标覆盖了可用性、可靠性、消费健康和资源健康四个维度。任何一项异常都需要立即响应。