消息队列

概述 凌晨三点，手机被告警轰炸。Kafka 某个消费者组的 Lag 从 200 飙到 50 万，下游实时报表全部卡住，数据团队在群里疯狂 at 你。你爬起来连上跳板机，敲 kafka-consumer-groups.sh --describe，看到 Lag 列一串刺眼的数字。接下来半小时，你要回答三个问题：积压在哪个分区？消费者是死了还是慢了？加机器能救吗？ 消息队列是分布式系统的"下水道"——平时没人关注，一旦堵了整栋楼都得停工。Consumer Lag（消费者延迟）就是下水道的流量计，它告诉你生产者往里灌水的速度和消费者抽水的速度差了多少。这个差值持续增大，说明系统出了问题；差值突然归零，也可能出问题（消费者挂了，offset 不再提交，Lag 反而看起来正常）。 这篇文章覆盖 Kafka、RabbitMQ、Redis 三种主流消息队列的监控方案，从指标采集、Prometheus 规则、告警阈值到排障思路，都是我在生产环境踩过坑的实战经验。不讲理论，直接上配置。 为什么 Consumer Lag 是最核心的指标 先说清楚 Lag 到底是什么。Kafka 里每个分区有一个 LogEndOffset（LEO，最新消息位置），消费者组有一个 CurrentOffset（已提交位置）。两者的差值就是 Lag： Lag = LogEndOffset - CurrentOffset Lag 为 0 说明消费者完全跟上。但生产环境小幅波动很正常，单分区 Lag < 100 基本不用管。真正要警惕的是三种模式： Lag 模式 典型原因 危险程度 持续线性增长 消费速度 < 生产速度，处理能力不足 高，不处理会雪崩 突然跳变 消费者重启/崩溃后 offset 回退，或生产者批量灌数据 中，需确认是否预期 突然归零 消费者挂了或跳过提交，offset 停滞但 LEO 也没涨 低但不正常，常被误判为"健康" 第三种最坑人。我见过一个案例：消费者线程死锁，但 auto.commit.enable=true 还在自动提交 offset，导致消息被标记为"已消费"但实际没处理。Lag 显示 0，业务方以为一切正常，直到下游发现数据丢了三天。...