准确监控消息积压需聚焦消费者视角滞后量：RabbitMQ用queue depth+unack count，Kafka避offset提交延迟取log_end-comitted_offset，NSQ重in_flight与requeue_count；须区分瞬时尖刺与持续恶化，动态基线告警。
消息积压不是“有没有”的问题，而是“积多少、为什么积、谁在积”的问题。Golang 项目里直接用 len(queue) 或查队列长度 API 往往不准——真正要监控的，是消费者视角的滞后量（lag），比如 Kafka 的 offset 差值、RabbitMQ 的 queue depth + unack count、NSQ 的 depth 与 in_flight 组合。
如何准确获取 RabbitMQ 队列积压量
RabbitMQ 自身不暴露“消费滞后”概念，queue.declare 返回的 message_count 只是就绪消息数，不包含 unacknowledged 消息。真实积压 = 就绪消息 + 正在处理但未确认的消息。
- 调用
channel.QueueInspect()获取Messages（就绪）和MessagesUnacknowledged（未确认）两个字段 - 避免轮询过频：RabbitMQ 管理插件 API（
/api/queues/{vhost}/{name}）有默认限速，建议 10–30 秒采样一次 - 注意 vhost 编码：URL 中的
/要转义为%2F，否则GET /api/queues/%2F/my_queue会 404 - 如果启用了
prefetch_count=1，MessagesUnacknowledged基本等于当前并发消费者数，此时积压主因是处理慢，而非堆积爆发
为什么 Kafka lag 监控不能只看 consumer group offset
kafka.ConsumerWithOffsetsAutoCommitInterval(500*time.Millisecond) 这类配置会让 offset 提交延迟不可控，导致 lag 计算失真。真实 lag 是 log_end_offset - committed_offset，但 committed_offset 可能已 stale。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 优先使用
ConsumerGroup.DescribeGroup()+AdminClient.ListOffsets()组合，绕过 commit 状态依赖 - 不要信任客户端内存里的
consumer.HighWaterMarkOffset()，它只反映最后一次 fetch 的 end offset，不实时 - 对多分区 topic，必须按
partition分别计算 lag，再聚合；某一分区 lag 爆涨常被全局平均值掩盖 - 若用 Sarama，注意
client.GetOffset(topic, partition, sarama.OffsetNewest)返回的是服务端当前最新 offset，不是 lag 值本身
NSQ 如何通过 /stats 接口识别隐性积压
NSQ 的 /stats 返回 JSON 中，topics 下每个 topic 的 channels 列表里，depth 是待消费消息数，但关键指标其实是 in_flight 和 requeue_count 的持续增长。
立即学习“go语言免费学习笔记（深入）”；
-
in_flight > 0且depth == 0：说明消费者卡在处理中，不是队列满，而是业务逻辑阻塞或网络超时 -
requeue_count每分钟上升 > 10 次：大概率存在消息解析失败、DB 连接池耗尽等可恢复错误，需结合日志查NSQD_LOG_LEVEL=2输出 - NSQ 不支持跨节点积压聚合，监控脚本必须遍历所有 nsqd 实例的
/stats，不能只连一个 lookupd - 注意
timeout参数：HTTP 请求带?format=json&verbose=1时响应可能变大，超时设太短会漏数据
积压监控最易被忽略的点：没有区分「瞬时尖刺」和「持续恶化」。告警阈值不能只设固定数字，比如 Kafka lag > 1000 就发短信——得结合过去 15 分钟的 P95 lag 值动态计算基线，否则每天凌晨定时任务一跑就狂告警。
