4. 监控体系搭建：JMX指标采集、Prometheus+Grafana看板设计、关键指标（BytesIn/Out、TotalFetchRequestsPerSec）

Kafka 堆积诊断的前提是“可观测”。没有实时、准确的监控数据，堆积治理就是盲人摸象。本章聚焦于搭建一套生产级的 Kafka 监控体系，覆盖从 JMX 指标暴露、Prometheus 采集到 Grafana 看板设计的完整链路，并深度解析 BytesIn/Out、TotalFetchRequestsPerSec 等核心指标在堆积场景下的判读方法。

4.1 监控架构总览

下图展示了从 Kafka Broker 到最终可视化看板的完整数据流。JMX 作为指标源，由 JMX Exporter 转换为 Prometheus 格式，Prometheus Server 定期拉取并存储，Grafana 通过 PromQL 查询渲染看板。

4.2 JMX 指标采集：从 Broker 到 Exporter

Kafka 原生使用 JMX（Java Management Extensions）暴露运行时指标。每个 Broker 启动时都会注册一组标准 MBean，涵盖网络、请求、日志、分区等多个维度。

4.2.1 关键 JMX MBean 路径

4.2.2 JMX Exporter 部署配置

推荐使用 prometheus/jmx_exporter 作为 Java Agent 附加到 Kafka Broker 进程。以下是一个最小化配置示例：

# jmx_exporter_config.yml
startDelaySeconds: 0
ssl: false
rules:
  # 捕获 BytesInPerSec 指标
  - pattern: "kafka.server<type=BrokerTopicMetrics, name=BytesInPerSec><>OneMinuteRate"
    name: "kafka_broker_bytes_in_per_sec"
    type: GAUGE
    labels:
      broker: "$1"
  # 捕获 BytesOutPerSec 指标
  - pattern: "kafka.server<type=BrokerTopicMetrics, name=BytesOutPerSec><>OneMinuteRate"
    name: "kafka_broker_bytes_out_per_sec"
    type: GAUGE
    labels:
      broker: "$1"
  # 捕获 TotalFetchRequestsPerSec
  - pattern: "kafka.server<type=BrokerTopicMetrics, name=TotalFetchRequestsPerSec><>OneMinuteRate"
    name: "kafka_broker_fetch_requests_per_sec"
    type: GAUGE
    labels:
      broker: "$1"

启动 Broker 时添加 JVM 参数：

KAFKA_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=8080:/opt/jmx_exporter/jmx_exporter_config.yml" \
./bin/kafka-server-start.sh config/server.properties

4.3 Prometheus 采集配置

在 Prometheus 的 prometheus.yml 中添加 Kafka Broker 的抓取目标。如果集群有多个 Broker，建议使用服务发现或静态配置列表。

# prometheus.yml 片段
scrape_configs:
  - job_name: 'kafka-broker'
    static_configs:
      - targets:
        - 'broker1.example.com:8080'
        - 'broker2.example.com:8080'
        - 'broker3.example.com:8080'
    metrics_path: '/metrics'
    scrape_interval: 15s
    scrape_timeout: 10s

4.4 Grafana 看板设计：堆积诊断视图

Grafana 看板是监控数据的最终呈现层。针对堆积诊断，我们设计三个核心面板：流量对比面板、请求速率面板、堆积趋势面板。

4.4.1 流量对比面板（BytesIn vs BytesOut）

该面板使用时间序列图，同时展示 BytesInPerSec 和 BytesOutPerSec 的 1 分钟速率。当 BytesIn 持续高于 BytesOut 时，说明消费端处理能力不足，堆积正在形成。

# PromQL 示例：BytesIn 与 BytesOut 对比
# BytesIn 1分钟速率
rate(kafka_broker_bytes_in_per_sec[1m])
# BytesOut 1分钟速率
rate(kafka_broker_bytes_out_per_sec[1m])

4.4.2 请求速率面板（TotalFetchRequestsPerSec）

TotalFetchRequestsPerSec 反映消费者拉取请求的频率。堆积发生时，如果该指标下降，说明消费者可能被阻塞或已停止拉取；如果该指标维持高位但 BytesOut 很低，说明消费者在频繁拉取但每次拉取的数据量很小（可能因为消息体过大或网络瓶颈）。

# PromQL 示例：Fetch 请求速率
rate(kafka_broker_fetch_requests_per_sec[1m])

4.4.3 堆积趋势面板（日志大小变化）

通过监控特定分区的日志大小（Log Size）变化，可以直接判断堆积是否在增长。建议按 Topic 分组聚合。

# PromQL 示例：按 Topic 聚合日志大小
sum by(topic) (kafka_log_log_size{topic=~".+"})

4.5 关键指标深度解析：堆积场景下的判读

以下表格总结了在堆积发生时，三个核心指标的典型表现模式：

4.6 告警规则设计

基于上述指标，可以设计以下 Prometheus 告警规则，实现堆积的自动检测：

# kafka_alerts.yml
groups:
  - name: kafka_lag_alerts
    rules:
      # 规则1：BytesOut 远低于 BytesIn 持续 5 分钟
      - alert: KafkaBytesOutLagging
        expr: |
          rate(kafka_broker_bytes_in_per_sec[5m])
          /
          rate(kafka_broker_bytes_out_per_sec[5m]) > 1.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Kafka BytesOut 落后 BytesIn 超过 50%"
          description: "Broker {{ $labels.instance }} BytesIn/BytesOut 比值 > 1.5，持续 5 分钟"

      # 规则2：Fetch 请求速率下降超过 30%
      - alert: KafkaFetchRequestsDropping
        expr: |
          rate(kafka_broker_fetch_requests_per_sec[5m])
          /
          avg_over_time(rate(kafka_broker_fetch_requests_per_sec[1h])[1h:]) < 0.7
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Kafka Fetch 请求速率异常下降"
          description: "当前 Fetch 速率低于过去 1 小时平均值的 70%"

4.7 本章小结

一套完整的 Kafka 监控体系是堆积诊断的基石。通过 JMX Exporter 暴露指标、Prometheus 统一采集、Grafana 可视化看板，运维人员可以实时掌握 BytesIn/Out 和 TotalFetchRequestsPerSec 等关键指标的变化。当 BytesIn 持续高于 BytesOut、Fetch 请求速率异常下降时，即可快速定位堆积风险，为后续的 API 治理和性能调优提供数据支撑。