Skip to main content

消费者 Lag 监控与解读

“Lag日志”其实有两种常见形式：一是你主动用命令查出来的状态报表，二是系统自己打印的监控日志。前者用来“看病”，后者用来“报警”。

🔍 形式一：命令行状态报表（最常用）​

这是排查问题的主力，通过 kafka-consumer-groups.sh --describe --group <group_id> 命令查看。

输出示例：

GROUP            TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG   CONSUMER-ID
my-cdc-sink      cdc.orders      0          4582910         4583200         290   consumer-1-abc123
my-cdc-sink      cdc.orders      1          4581000         4583195         2195  consumer-2-def456
my-cdc-sink      cdc.orders      2          4400000         4583180         183180 consumer-3-ghi789
my-cdc-sink      cdc.orders      3          4583100         4583210         110   consumer-1-abc123

各列含义：

  • CURRENT-OFFSET：消费者当前已读到的位置。
  • LOG-END-OFFSET：生产者最新写到的位置（即分区末尾）。
  • LAG：堆积量 = LOG-END-OFFSET - CURRENT-OFFSET。这个值越大，说明积压越严重。

怎么看懂它？

  • 看总量与趋势：持续增长说明消费速度跟不上生产速度。
  • 看分布：如果所有分区 Lag 差不多，通常是整体变慢了；如果像示例中 Partition 2 的 Lag 异常高（183,180），说明分区键（Partition Key）分配不均导致数据倾斜。
  • 看状态：命令输出顶部还会显示 STATE。Stable 表示正常；Rebalancing 表示正在重平衡；Empty 或 Dead 则表示消费者已宕机，需要立即检查服务。

📝 形式二：应用程序监控日志​

这是系统在后台定时打印的，方便你集成到监控系统里。

日志示例：

2022-11-27 02:33:23,625 [kafka-consumer-stats-1-thread-1] INFO  o.t.m.b.q.k.s.TbKafkaConsumerStatsService - [msg-all-consumer-group] Topic partitions with lag: [[topic=[tbmq.msg.all], partition=[2], lag=[5]]]

这条日志直接告诉你：msg-all-consumer-group 这个消费者组在 tbmq.msg.all 主题的 2号分区上，堆积了5条消息没处理。

总结一下：你遇到 Lag 告警时，第一反应应该是敲下 kafka-consumer-groups.sh --describe 命令，去看 LAG 列和 STATE。Lag 持续增长或分布严重不均，再配合我们上次聊的“频繁Rebalance”的原因一起排查，思路就清晰了。

等你实际跑出命令行结果，可以把输出贴给我，我帮你具体分析。😎