监控消息队列的积压，关键在于实时待处理数、增长趋势以及处理能力的变化。不同的队列系统，其监控方法有所不同，需要根据队列类型选择合适的数据源：Redis队列可以使用LLEN命令来查询queues:high的长度；Horizon则需关注pending数以及jobs/min、a vg.duration是否异常；RabbitMQ需要调用HTTP API来获取messages_ready/unacknowledged；Prometheus则可以统一采集并告警。

监控消息队列积压，关键在于紧盯“待处理但未消费”的实时数量、增长趋势以及处理能力的变化，而非仅仅关注“有没有消息”。不同的队列系统，比如Lara vel Horizon/Redis、RabbitMQ、Kafka等，方法虽有差异，但核心逻辑是一致的：找对数据源、设置好阈值，并及时发出告警。

查 Redis 队列长度（Lara vel/自建 Redis 队列适用）

Redis 是 Lara vel 默认队列后端，high/default 等队列实际以 list 形式存在，键名通常是 queues:high（前缀受 HORIZON_PREFIX 影响）。它的长度最接近真实积压量：

• 直接执行：redis-cli LLEN queues:high，返回整数即当前等待任务数
• 脚本化检测：每 20–30 秒运行一次，值 ≥ 80 就写日志或发钉钉/邮件
• 注意：比 Horizon 页面显示更实时，绕过了 Horizon 的 5 秒采样缓存

用 Horizon 看队列健康度（Lara vel 专用）

Horizon 不只是看数字，它能反映“是否真卡住”：

• 访问 /horizon → “Queues” 标签页 → 找 high 队列 → 看 Pending jobs
• 点进去看详情：Jobs per minute 是否断崖下跌？A vg. duration 是否明显拉长？两者同时恶化，说明不是单纯流量大，而是有阻塞任务（如 DB 锁、HTTP 超时）
• 程序调用：GET /horizon/api/metrics 解析 queues.high.waiting 字段，用于自动告警

调 RabbitMQ HTTP API（RabbitMQ 场景）

RabbitMQ 自带管理插件，暴露结构化指标，比手动 queue.declare passive 更准、更全：

• 请求：GET /api/queues/%2Fprod/order_created（vhost 要 URL 编码）
• 重点字段：messages_ready（就绪可消费）、messages_unacknowledged（已取走但未确认）——后者持续高，说明消费者卡死或没发 ack
• 建议每 15 秒查一次，超时加 context.WithTimeout 防止监控 goroutine 挂住

暴露 Prometheus 指标（通用扩展方案）

不管底层是 Redis、RabbitMQ 还是文件队列，只要能读出积压数，就能统一接入 Prometheus 告警体系：

• 写个轻量 Python/Go Exporter，定时采集并暴露为 queue_backlog{queue="high", broker="redis"}
• PromQL 示例：rate(queue_backlog{queue="high"}[5m]) > 10（5 分钟内平均积压增速超 10 条/分钟）
• 配合 Alertmanager，触发企业微信或电话告警，比 cron + shell 更可靠