深色模式
Kafka 消费滞后监控
摘要：消费滞后（lag）是 Kafka 运维最重要的健康信号——它直接反映生产者快过消费者的程度。本文教你用命令行查看 lag、用 JMX exporter 把它变成 Prometheus 指标、设置分级告警，并给出滞后的常见原因与处置顺序。
适用环境
bash
# 确认 Kafka 已运行
/opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 --list
# 查看当前所有消费者组
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list
# 确认 JMX 端口（启动 broker 时通过 JMX_PORT 环境变量开启）
echo $JMX_PORT1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
操作步骤
1. 用命令行查看 lag
bash
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer1
2
2
输出关键列：CURRENT-OFFSET（已消费位点）、LOG-END-OFFSET（最新位点）、LAG（差值）。LAG 持续增长就是消费能力不足。
2. 找出滞后最严重的分区
bash
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer 2>/dev/null \
| awk 'NR>1 && $6>0 {print $2, $3, $6}' | sort -k3 -nr | head -101
2
3
2
3
3. 开启 JMX 并暴露指标
bash
# 启动 broker 前设置环境变量（systemd 里写在 Environment=）
export JMX_PORT=9999
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"
sudo systemctl restart kafka1
2
3
4
2
3
4
配合 JMX exporter 把 kafka.consumer:type=consumer-fetch-manager-metrics 下的 records-lag-max 转成 Prometheus 指标。
yaml
# jmx_exporter 配置片段（kafka-2_0_0.yml 思路）
rules:
- pattern: 'kafka.consumer<type=(.+), client-id=(.+), topic=(.+), partition=(.+)><>records-lag-max'
name: kafka_consumer_records_lag_max
labels: {client_id: "$2", topic: "$3", partition: "$4"}1
2
3
4
5
2
3
4
5
4. 用命令行脚本做轻量监控（没有 exporter 时的兜底方案）
bash
cat > /usr/local/bin/check_kafka_lag.sh <<'EOF'
#!/usr/bin/env bash
BOOTSTRAP=localhost:9092
GROUP=$1
WARN=${2:-1000}
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server "$BOOTSTRAP" \
--describe --group "$GROUP" 2>/dev/null \
| awk -v w=$WARN 'NR>1 && $6>w {print "LAG HIGH:", $2, $3, $6}'
EOF
chmod +x /usr/local/bin/check_kafka_lag.sh
/usr/local/bin/check_kafka_lag.sh order-consumer 10001
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
5. 配置分级告警规则
yaml
# Prometheus rules 片段
groups:
- name: kafka-lag
rules:
- alert: KafkaConsumerLagHigh
expr: sum(kafka_consumer_records_lag_max) by (topic, consumergroup) > 10000
for: 5m
labels: {severity: warning}
annotations: {summary: "{{ $labels.consumergroup }} 消费滞后超过 1 万条"}
- alert: KafkaConsumerLagCritical
expr: sum(kafka_consumer_records_lag_max) by (topic, consumergroup) > 100000
for: 10m
labels: {severity: critical}
annotations: {summary: "消费严重滞后，需立即扩容消费者"}1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
6. 处置滞后：先扩容消费者，再查消费逻辑
bash
# 增加消费者实例（数量不超过分区数，多余的会空闲）
# 永久调整分区数：分区只能增不能减
/opt/kafka/bin/kafka-topics.sh --bootstrap-server localhost:9092 \
--alter --topic demo-topic --partitions 121
2
3
4
2
3
4
DANGER
增加分区会改变 key 到分区的映射，正在按 key 保序消费的业务会出现短暂乱序。分区扩容要在业务低峰期做，并提前确认消费端不依赖全局顺序。
验证
bash
# 1) 制造滞后：暂停消费者，持续生产，观察 LAG 上升
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer
# 2) 确认 JMX 指标可采集
curl -s http://127.0.0.1:9404/metrics | grep records_lag_max | head -3
# 3) 告警是否触发（Prometheus UI 的 Alerts 页面查看）
curl -s http://127.0.0.1:9090/api/v1/alerts | head -201
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
常见坑
WARNING
消费者实例数超过分区数时，多余的消费者完全收不到消息（处于空闲）。扩容前先确认 分区数 >= 消费者数，否则扩容毫无效果。
WARNING
--describe 看不到消费者组，通常是因为消费者用的是不同 group.id，或消费的是其他集群。先用 --list 确认组名拼写。
DANGER
auto.offset.reset=earliest 在新组上线时会从头消费历史全量数据，瞬间打出巨大 lag 并可能冲垮下游。生产环境新组务必确认该参数取值，必要时显式 --to-latest 重置位点。