Kafka 应该监控哪些指标

← 上一篇 Kafka Quotas：如何限制 Producer 和 Consumer 的流量

验证：先看JVM本身健不健康——jstat -gc

命令 · shell $ jstat -gcutil <broker2的pid>

真实实测 · 本机执行输出

  S0     S1     E      O      M     CCS    YGC     YGCT     FGC    FGCT     CGC    CGCT       GCT
  0.00  86.07  91.04  23.11  97.63  91.65     10     0.035     0     0.000     4     0.002     0.037

FGC=0(Full GC次数为0)和O=23.11(老年代只用了23%)真实是健康的信号——如果一个broker真实频繁触发Full GC，或者老年代占用长期接近100%，通常意味着堆内存配置太小，或者真实存在内存泄漏，GC停顿本身会真实拖慢broker处理请求的速度，进而影响到所有连接它的客户端。

验证：再看集群层面——本系列前面已经反复用过的几个命令

命令 · shell(汇总本系列真实用过的检查手段) $ kafka-consumer-groups.sh --describe --group X # 真实查LAG，见《Consumer Lag 到底怎么算》 $ kafka-topics.sh --describe --topic Y # 真实对比Isr和Replicas，长度不一致=有副本掉线 $ kafka-metadata-quorum.sh describe --status # 真实查controller quorum是否健康，见《KRaft Controller Quorum》 $ kafka-log-dirs.sh --describe --topic-list Y # 真实查磁盘占用和offsetLag，见《Replica Fetcher》

这份清单里没有一条是本文新发明的——每一条真实都是本系列前面某篇文章里已经真实跑过、验证过含义的命令。把它们串起来看，真实构成了一条从JVM本身、到单个topic的副本健康度、到整个集群的controller状态、再到磁盘占用的完整巡检路径：JVM出问题(FGC频繁)会拖慢broker响应，broker响应慢会导致副本ISR掉线(Isr比Replicas短)，ISR长期不健康会影响controller做决策的可靠副本池，磁盘占用异常增长(用kafka-log-dirs.sh查)则是容量规划要盯的指标。真实的监控体系不需要一开始就上Prometheus+JMX Exporter这套重型方案，先把这几条命令串成一个每天/每次发布前跑一遍的检查脚本，已经能覆盖大部分真实的日常异常。

分步演示：一份真实可执行的监控清单

每一步都是本文上面用真实命令跑出来的原始结果。

从JVM健康到集群健康的一条真实巡检路径

这一步新验证的检查项

参考与说明

数据来自本机3节点Kafka 4.3.1集群的broker2真实运行状态，jstat为JDK自带工具。
本文引用的4篇前置文章：《Consumer Lag 到底怎么算》《Partition Leader 是怎么选出来的》(ISR对比)《KRaft Controller Quorum 如何选主》《Replica Fetcher》，每一条命令的真实含义都在对应文章里验证过。
没有验证：真实的kafka.tools.JmxTool在Kafka 4.3.1里已经不存在(ClassNotFoundException)，本文用jstat作为JVM层面的替代检查手段；生产环境用Prometheus JMX Exporter采集的完整指标面板，本文没有搭建。

下一篇 · KAFKA 内部原理 70

Kafka 常见故障排查路径