《Kafka: The Definitive Guide》 第十章：Kafka 监控详解
Kafka 是一个分布式、高吞吐、可扩展的流处理平台。但要让它在生产环境中“稳定可靠”，监控（Monitoring）系统运行状态是核心保障手段之一。
- Kafka 各组件的关键指标；
- 如何收集指标（JMX、Exporter、日志等）；
- 可视化与报警机制；
- 如何根据指标发现问题并定位故障。
一、Kafka 为什么必须监控？
Kafka 的分布式特性带来了灵活性和可扩展性，但也意味着：
- 一处 Broker 出现问题可能引发集群级别连锁故障；
- 消息堆积、延迟、ISR 异常等往往不容易第一时间感知；
- 没有监控系统，你不知道“发生了什么、什么时候发生、严重到什么程度”。
因此监控的核心目标是：早发现、快定位、准判断、能自愈。
二、Kafka 可观测数据来源
Kafka 主要通过以下三类方式暴露运行时指标：
1. JMX（Java Management Extensions）
Kafka 是 JVM 应用，核心组件都通过 JMX MBeans 暴露监控指标，例如：
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec
- 默认端口：
9999（可通过KAFKA_JMX_PORT设置）； - 可通过
jconsole、jmxterm等工具手动查看； - 常配合 JMX Exporter（Prometheus 插件）自动采集。
2. 日志文件
Kafka 使用 log4j，包括：
- server.log：Broker 主日志；
- controller.log：副本、leader、分区控制相关；
- state-change.log：副本状态变更；
- cleaner.log：日志压缩详情。
日志适合排查问题，但不适合做时间序列监控。
3. 外部采集组件
- Prometheus + Grafana：主流方案，Kafka → JMX Exporter → Prometheus → Grafana；
- Confluent Control Center：Confluent 提供的商业化可视化平台；
- Datadog、New Relic、InfluxDB：多平台支持 Kafka JMX 数据接入。
三、关键指标详解（按组件）
Kafka 监控指标繁多，但以下是生产环境中最常用、最关键的指标列表，按角色分类。
Broker 级别指标（BrokerTopicMetrics）
| 指标名称 | 说明 | 常见问题预警 |
|---|---|---|
MessagesInPerSec |
每秒写入的消息数量 | 突然激增/骤减 |
BytesInPerSec |
每秒写入字节数 | 压力判断 |
BytesOutPerSec |
每秒出站流量 | 消费瓶颈 |
RequestHandlerAvgIdlePercent |
Handler 空闲比例 | 过低表示压力大 |
UnderReplicatedPartitions |
副本不一致分区数 | > 0 说明副本同步异常 |
OfflinePartitionsCount |
不可用分区数 | >= 1 说明服务降级 |
ActiveControllerCount |
主控制器数量 | != 1 表示问题 |
Topic / Partition 指标
| 指标名称 | 说明 |
|---|---|
LogEndOffset |
分区当前最新的 offset |
LogStartOffset |
日志段起始 offset（受保留策略影响） |
Size |
分区占用磁盘大小 |
IsrShrinksPerSec / IsrExpandsPerSec |
ISR 缩减/恢复频率，表示副本健康状况 |
Producer 侧指标
| 指标名称 | 说明 |
|---|---|
record-send-rate |
每秒发送消息数 |
record-error-rate |
错误发送比例 |
request-latency-avg |
请求延迟 |
bufferpool-wait-time |
等待 buffer 时间，>0 说明生产受阻 |
batch-size-avg |
批量大小，影响吞吐 |
Consumer 侧指标
| 指标名称 | 说明 |
|---|---|
records-lag |
当前消费滞后数（最关键） |
fetch-rate |
每秒拉取消息数 |
commit-rate |
offset 提交速率 |
poll-latency-avg |
消费延迟，>100ms 说明压力高或反应慢 |
四、监控方案搭建实战（Prometheus + Grafana）
1. 启用 JMX Exporter（以 Kafka Broker 为例）
# kafka-run-class.sh 中加入以下配置
KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9999 \
-Dcom.sun.management.jmxremote.rmi.port=9999 \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=7071:/opt/jmx_exporter/kafka-2_0_0.yml"
其中：
7071是导出 Prometheus 指标的端口；kafka-2_0_0.yml是采集哪些 MBean 的配置文件。
2. Prometheus 配置示例
scrape_configs:
- job_name: 'kafka'
static_configs:
- targets: ['kafka1:7071', 'kafka2:7071']
3. Grafana 模板
Grafana 社区或 Confluent 提供了丰富的 Kafka 监控仪表板模板，涵盖：
- Kafka Broker 运行状况；
- 消费者滞后；
- Topic 增长趋势；
- 错误率分析；
- 网络与磁盘 I/O。
五、设置报警规则（Prometheus Alertmanager）
以下是一些典型告警规则示例：
- alert: KafkaOfflinePartitions
expr: kafka_controller_kafkacontroller_offlinepartitionscount > 0
for: 2m
labels:
severity: critical
annotations:
description: "Kafka 有分区不可用"
- alert: KafkaConsumerLagHigh
expr: kafka_consumer_group_lag > 10000
for: 5m
labels:
severity: warning
annotations:
description: "消费者滞后过高"
- alert: KafkaUnderReplicatedPartitions
expr: kafka_cluster_partition_underreplicated > 0
for: 1m
labels:
severity: warning
六、常见问题诊断策略
| 症状 | 常见原因 | 诊断指标 |
|---|---|---|
| 消费滞后严重 | 消费者太慢、Topic 写入过快 | records-lag |
| 副本同步失败 | Broker 压力大或网络延迟高 | UnderReplicatedPartitions |
| 延迟高 | 生产/消费端阻塞、磁盘慢 | request-latency, poll-latency |
| Controller 频繁变动 | 网络波动、ZooKeeper 异常 | ActiveControllerCount |
七、小结
Kafka 作为流平台的中枢，一旦出现异常将波及所有上下游系统，因此必须部署完备的 监控 + 报警体系：
- Prometheus + Grafana 是目前主流、免费、生态完善的监控方案；
- Kafka 的 Broker / Topic / Producer / Consumer 都需要单独监控视角；
- 建议配合 自动重启、动态扩缩容、日志告警、性能趋势分析 等工具使用；
- 监控数据也是后续 调优、容量规划、故障定位 的关键数据支撑。