凌晨3点报警响了——Kafka集群监控哪些指标必须盯？
先说结论
Kafka监控分三层：Broker层（集群健康）、Topic层（数据流向）、Consumer层（消费健康）。最核心的指标是Consumer Lag——Lag持续增长就意味着下游在延迟，必须立刻处理。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
做过Kafka运维的人都知道，最怕的不是Kafka出问题，而是出了问题你不知道。在某元宇宙社交公司搭建实时数仓的时候，我从0建立了Kafka的监控体系，踩过不少坑——有一次Consumer Lag飙了30分钟我才发现，产品经理的实时大盘已经白板半天了。后来把监控和报警做到位，再没出过类似的乌龙。面试官问监控，其实是在考你的生产运维经验。
必须监控的核心指标
| 层级 | 指标 | 含义 | 报警阈值（参考） |
|---|---|---|---|
| Broker | 磁盘使用率 | Kafka数据全在磁盘上 | Warning>80%, Critical>90% |
| Broker | ISR Shrink/Expand | ISR频繁变化说明副本同步不稳定 | 每小时>5次 |
| Broker | Under-Replicated Partitions | 有副本没跟上Leader | >0持续5分钟 |
| Broker | Active Controller Count | 整个集群应该只有1个Controller | !=1 |
| Topic | Bytes In/Out Rate | Topic的写入/读取速率 | 按业务基线设 |
| Consumer | Consumer Lag | 消费积压量 | Warning>1万, Critical>10万 |
| Consumer | Lag增长趋势 | Lag是否在持续增加 | 持续增长>10分钟 |
Consumer Lag监控——最重要的指标
Consumer Lag是我监控体系里权重最高的指标。Lag = Log End Offset - Consumer Current Offset，表示还有多少条消息没被消费。
# 方式一：命令行查看（排查时用）
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
--describe --group flink-realtime-dashboard
# 方式二：JMX指标（接入Prometheus用）
# kafka.consumer:type=consumer-fetch-manager-metrics
# records-lag-max ← 最大Lag
# records-lag-avg ← 平均Lag
# 方式三：Flink内置指标（最推荐）
# Flink暴露的Kafka Consumer指标：
# currentOffsets ← 当前消费位置
# committedOffsets ← 已提交位置
# records-lag ← 每个Partition的Lag
# 直接接Prometheus + Grafana，实时看趋势报警策略我一般分两级：
Warning：Lag > 1万条持续5分钟 → 发飞书/钉钉通知，开发确认。
Critical：Lag > 10万条 或 Lag持续增长超过30分钟 → 电话报警，立刻排查。
Broker层监控——集群健康检查
① 磁盘使用率：Kafka的数据全存磁盘上。磁盘满了Broker直接宕机，而且数据可能丢失。我在元宇宙社交公司设的策略是：80%告警开始清理过期数据、90%严重报警、95%紧急扩容或手动删除低优先级Topic的数据。
② Under-Replicated Partitions：表示有Partition的Follower副本没有跟上Leader。如果这个值>0持续超过5分钟，说明某个Broker有问题（网络慢、磁盘IO高、GC暂停）。这是Broker层最需要关注的健康指标。
# 查看Under-Replicated Partitions
kafka-topics.sh --bootstrap-server broker1:9092 \
--describe --under-replicated-partitions
# 如果有输出，说明某些Partition的副本没跟上
# 排查步骤：
# 1. 看是哪个Broker上的副本掉队了
# 2. 检查该Broker的磁盘IO、网络、GC日志
# 3. 常见原因：磁盘IO满了、网络带宽不够、JVM GC暂停过长我的监控体系搭建经验
在某元宇宙社交公司，我搭建的Kafka监控体系是这样的：
| 组件 | 用途 | 关键配置 |
|---|---|---|
| Know Streaming | Kafka集群可视化管理 | Topic管理、Lag查看、Broker状态 |
| Prometheus | 指标采集和存储 | JMX Exporter采集Kafka指标 |
| Grafana | 监控大盘和趋势图 | 按Broker/Topic/ConsumerGroup分面板 |
| 飞书机器人 | 报警通知 | Warning走群消息，Critical走电话 |
在某短剧出海公司用的是云厂商托管的Kafka，自带监控面板和报警配置，不需要自己搭Prometheus。但核心指标和报警逻辑是一样的。
实战踩坑：报警没配好差点出大事
在元宇宙社交公司刚搭完实时数仓的前两周，报警还没配好。有一次晚高峰gift_txn的Consumer Lag从几百飙到30万，但我完全不知道。直到产品经理来找我说'实时大盘半小时没数据了'，我才去查。原因是Doris在做compaction导致Flink写入变慢（第4篇讲过的那次踩坑）。
这次之后我用了一个周末把完整的监控报警搭了起来：Know Streaming看集群状态、Prometheus+Grafana看指标趋势、飞书机器人推报警。后来又有一次类似的情况，Lag刚开始涨的3分钟内我就收到了Warning，5分钟内定位到问题并处理，产品经理完全无感知。
教训：监控和报警是生产环境的第一优先级。不要等出事了才补，要在上线前就建好。这个经验我后来带到了每一家公司。
面试高频追问
追问一：Kafka的JMX指标怎么采集？
在Kafka Broker启动时加上JMX参数（KAFKA_JMX_OPTS），然后用Prometheus的JMX Exporter作为Java Agent挂载到Broker进程上，就能把Kafka的内部指标暴露为Prometheus格式。Grafana直接查询Prometheus展示。
追问二：怎么判断Kafka集群需要扩容？
三个信号：① Broker CPU持续>70%；② 磁盘使用率接近80%且增长趋势不减；③ Consumer Lag在业务低峰期也降不下来。扩容优先加Broker，然后把热点Topic的Partition重新分配到新Broker上。
总结
Kafka监控面试答三层：Broker层（磁盘、ISR、Under-Replicated）、Topic层（吞吐量）、Consumer层（Lag是核心）。报警分两级：Warning通知、Critical电话。能讲出自己搭建监控体系的经历和踩坑故事，面试官会觉得你不只是会写代码的开发，还有运维和全局视野。
下一篇聊一个生产常见问题：某个Partition的消息量是其他的10倍——Kafka的数据倾斜怎么解决？
你们Kafka的监控体系是什么样的？用什么工具？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长