📚 课程目录第3章关键性能指标与监控体系

3. 关键性能指标与监控体系

Kafka 的性能问题很少以“单点故障”的形式出现，它通常表现为一组指标同时偏离基线：吞吐量下降、端到端延迟上升、ISR 频繁收缩、请求队列堆积、磁盘 IO 饱和、网络带宽打满、GC 停顿变长。要定位瓶颈，必须先把这些指标按“客户端—Broker—操作系统—JVM”四层建立监控体系，并理解它们之间的因果链，而不是孤立地看某一个数字。

一、四层指标体系与关键阈值

第一层是客户端指标，关注生产端与消费端的实际体验。生产端核心是 record-send-rate（每秒发送记录数）、record-error-rate、request-latency-avg/max 以及 buffer-available-bytes；消费端核心是 records-consumed-rate、records-lag-max 与 fetch-latency-avg。其中 records-lag-max 是消费滞后的直接体现，若持续增长，说明消费能力跟不上生产速率。

第二层是 Broker 指标，这是容量规划的主战场。吞吐量看 BytesInPerSec 与 BytesOutPerSec；请求处理看 RequestQueueSize（请求队列长度）与 RequestHandlerAvgIdlePercent（请求处理线程空闲率）；副本健康看 UnderReplicatedPartitions、IsrShrinksPerSec、IsrExpandsPerSec；分区与 Leader 看 OfflinePartitionsCount、ActiveControllerCount。经验上，RequestHandlerAvgIdlePercent 长期低于 0.3 表示请求处理线程接近饱和；RequestQueueSize 持续大于 0 且波动上升，说明请求到达速率已超过处理能力。

第三层是操作系统指标：磁盘 await、%util、iops，网络 bytes_sent/recv、重传率，以及 CPU 的 iowait。Kafka 的顺序写对磁盘友好，但一旦 %util 接近 100% 且 await 明显升高，说明磁盘已成为写路径瓶颈。第四层是 JVM 指标：heap_used、gc_pause_ms、gc_count。G1 下若单次 Full GC 超过 1 秒，或 Young GC 频率过高，都会直接推高请求延迟。

二、监控采集路径与配置要点

JMX 是最底层的采集入口。Broker 启动时通过 KAFKA_JMX_OPTS 暴露端口，例如：

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"
export JMX_PORT=9999

随后可用 kafka-run-class.sh kafka.tools.JmxTool 直接读取，例如查看某 Broker 的入站字节速率：

kafka-run-class.sh kafka.tools.JmxTool \
  --object-name kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec \
  --jmx-url service:jmx:rmi:///jndi/rmi://broker1:9999/jmxrmi \
  --reporting-interval 5000

Metrics API 则更适合接入 Prometheus。Confluent 提供 confluent.metrics.reporter，在 Broker 配置中启用后，指标会以标准格式暴露，Prometheus 按 scrape_interval 拉取，Grafana 负责展示与告警。Control Center 适合快速巡检：在集群概览页可看到 Broker 的吞吐、URP、请求队列曲线，在 Topic 详情页可看到分区级 ISR 变化与消费滞后。

三、从指标到判断：一个排障示例

假设某集群在业务高峰期出现生产延迟从 15ms 升至 220ms。按四层顺序排查：客户端 request-latency-max 升高，buffer-available-bytes 下降；Broker 层 RequestQueueSize 从 0 升至 180，RequestHandlerAvgIdlePercent 从 0.55 降至 0.18；OS 层磁盘 %util 达到 96%，await 从 2ms 升至 45ms；JVM 层 GC 正常。由此可判断瓶颈在磁盘写路径，而非 JVM 或网络。处理方向是检查是否有大量非顺序写、是否与其他 IO 密集型进程混部、是否应增加分区或迁移部分分区到低负载 Broker。

建议为每个关键指标设置两级阈值：警告线取基线 P95 的 1.5 倍，严重线取 2 倍。例如 RequestQueueSize 基线为 0，警告线可设为 50，严重线设为 200；UnderReplicatedPartitions 基线为 0，一旦大于 0 持续 1 分钟即告警。

四、指标与容量规划的对应关系

指标	正常参考	容量含义
RequestHandlerAvgIdlePercent	> 0.3	低于 0.3 需增加 Broker 或优化请求处理
RequestQueueSize	接近 0	持续大于 0 说明请求到达速率超过处理能力
UnderReplicatedPartitions	0	大于 0 表示副本同步能力不足，需检查磁盘与网络
IsrShrinksPerSec	接近 0	频繁收缩说明 Broker 不稳定或负载过高
磁盘 %util	< 70%	接近 100% 时写路径已饱和，需扩容或分离日志盘
网络带宽	< 70% 网卡上限	副本同步与消费流量叠加后易打满
GC pause	Young < 50ms，Full < 1s	停顿过长会直接推高请求延迟

把这些指标按四层组织成看板，并保留至少 30 天的历史数据，才能在容量规划时回答“当前负载下还能撑多久”“扩容后哪个指标先改善”这类问题。监控体系的价值不在于指标数量，而在于当异常发生时，能沿着因果链快速定位到具体层级和具体资源。