为什么要盯这几类指标
Kafka 的故障很少直接表现为「broker 挂了」，多数时候是副本落后、控制器切换或消费积压，最后以业务侧延迟的形式暴露出来。运维面板至少要覆盖四类：副本健康（URP 与离线分区）、控制器状态、流量与请求延迟、消费积压。缺任何一类，排障就只能靠猜。
基本信息
| 采集方式 | broker JMX 指标、kafka_exporter、客户端自带指标 |
|---|---|
| 常用端口 | JMX 默认开放端口由启动参数指定，如 9999 |
| 展示 | Prometheus + Grafana，或自建采集入库 |
| 覆盖对象 | broker、topic/分区、消费组三层都要有 |
| 告警基线 | URP 持续大于 0、lag 持续增长、控制器数不为 1 |
关键指标怎么读
| 维度 | 关键指标 | 含义与判读 |
|---|---|---|
| 副本 | UnderReplicatedPartitions | 副本落后数量，持续大于 0 需要排查 |
| 副本 | OfflinePartitionsCount | 无可用 leader 的分区数，大于 0 即有数据不可读 |
| 副本 | IsrShrinksPerSec / IsrExpandsPerSec | ISR 收缩突增说明副本同步跟不上 |
| 控制器 | ActiveControllerCount | 全集群之和应恰好为 1，为 0 表示无主 |
| 流量 | BytesInPerSec / BytesOutPerSec | 集群进出流量，用于识别异常波形 |
| 积压 | consumer lag（按组/分区） | 消费进度与末尾位移之差，看趋势不看瞬时值 |
| 请求 | TotalTimeMs / 错误率 | 客户端超时与重试的根因线索 |
JMX 与采集
JMX 与采集
# 多数发行版默认暴露 JMX（如 9999 端口）
JMX_PORT=9999 kafka-server-start.sh -daemon config/server.properties
# Prometheus 生态常用 kafka_exporter 抓取 broker 指标，再配 Grafana 面板
# 命令行快速看某个消费组积压（需要 Kafka 2.0+）
kafka-consumer-groups.sh --bootstrap-server broker:9092 --describe --group my-group典型使用场景
- 值班排障：先看 URP 与离线分区，判断是集群问题还是下游问题
- 容量规划：用 BytesIn/BytesOut 与磁盘增长趋势推算扩容时间点
- 发版观测：发版窗口内盯 lag 与请求延迟，确认没有引入消费阻塞
- 告警阈值设定：lag 用增长率而不是绝对值，避免业务波峰误报
- 定位客户端问题：同时看 broker 端请求耗时与客户端重试次数
先建面板再排障：URP、活跃 controller、ISR 收缩、lag 四条曲线能覆盖多数值班场景，比临时敲命令快得多。
lag 是「末尾位移减已提交位移」，分区多且流量不均时要按分区看，只看组级汇总值会把单个卡住的分区平均掉。