Kafka监控需打通采集、转换、存储、可视化全链路，核心是通过JMX Exporter桥接Kafka的MBean指标，重点监控UnderReplicatedPartitions、OfflinePartitionsCount等Broker级状态，并合理配置Exporter、Prometheus抓取及Grafana看板。
要让 Kafka 系统状态指标真正可观察、可告警、可分析，核心不是“连上 Prometheus 就完事”，而是打通从指标采集、转换、存储到可视化的完整链路。关键在于：Kafka 本身不直接输出 Prometheus 格式数据，必须通过 JMX Exporter 做协议桥接；而系统状态指标（如 Broker 健康、副本同步、磁盘压力）又高度依赖 JMX 暴露的底层 MBean，不能只靠外围 exporter。
Broker 层核心状态指标必须监控
Kafka 集群是否健康，首先看 Broker 级别指标是否稳定：
- UnderReplicatedPartitions：值为 0 是理想状态；大于 0 表示有分区副本未及时同步，可能引发数据丢失风险
- OfflinePartitionsCount：应恒为 0；非零说明分区 leader 已不可用，消费者将无法读取对应分区
- ActiveControllerCount：整个集群只能有且仅有 1 个活跃 controller；若为 0，说明 controller 选举失败，元数据更新将停滞
- RequestHandlerAvgIdlePercent：反映网络线程空闲率，低于 20% 意味着请求处理能力接近瓶颈，需关注延迟或堆积
- LogFlushRateAndTimeMs：日志刷盘耗时突增（如 p99 > 500ms），往往指向磁盘 IO 或文件系统问题
JMX Exporter 配置决定能看什么
很多团队监控“没效果”，根源在 Exporter 配置太粗放或太保守：
- 避免使用
pattern: ".*"全量采集——会产生数万指标，拖慢 Prometheus 并掩盖关键信号 - 优先启用
lowercaseOutputName: true，统一命名风格，方便 PromQL 查询和 Grafana 变量引用 - 对关键指标显式定义类型（
type: GAUGE或type: COUNTER），避免 rate() 计算出错 - 把
kafka.server、kafka.cluster、kafka.network三大类 MBean 的高频状态指标单独建 rule，例如：- pattern: 'kafka.server<type name="UnderReplicatedPartitions">Value' name: kafka_broker_under_replicated_partitions</type>
Prometheus 抓取配置要匹配部署模式
静态配置适用于单节点测试，生产环境必须适配实际架构：
- 物理机/VM 部署：在
static_configs中明确列出每个 Broker 的 JMX Exporter 地址（如kafka-broker-01:11001） - Docker Compose：用服务名+端口（如
kafka0:11001），确保容器网络互通 - Kubernetes：必须用
ServiceMonitor+ LabelSelector 自动发现 Pod，配合 Sidecar 注入 JMX Exporter，避免硬编码 IP - 抓取间隔设为
scrape_interval: 15s较合理；太短加重负载，太长会错过瞬时抖动
Grafana 看板要聚焦“状态判断”而非“数据罗列”
一个有效的 Kafka 状态看板，不是堆砌图表，而是回答几个关键问题：
- 当前有没有 Broker 不在线？→ 用
count by (instance) (kafka_broker_state{state="Running"} == 0)做红绿灯面板 - 哪些 Topic 出现严重滞后？→ 按
kafka_consumer_lag{group=~".+"}排序 TopN，标出超阈值（如 >10000）项 - 副本同步是否持续掉队？→ 查
rate(kafka_broker_under_replicated_partitions[1h])走势，结合告警规则 - 磁盘空间是否逼近红线？→ 关联
jvm_memory_usage_used_bytes{memory_type="Heap"}和node_filesystem_avail_bytes综合判断 - 消费组是否频繁 Rebalance？→ 统计
count_over_time(kafka_consumer_group_rebalance_total[1h])，突增即预警
