监控消息队列积压关键在于实时待处理数、增长趋势及处理能力变化；需依队列类型选数据源——redis用llen查queues:high长度，horizon看pending数与jobs/min、avg.duration异常，rabbitmq调http api取messages_ready/unacknowledged，prometheus则统一采集告警。
监控消息队列积压，关键不是只看“有没有消息”，而是盯住“待处理但未消费”的实时数量、增长趋势和处理能力变化。不同队列系统（如 Laravel Horizon/Redis、RabbitMQ、Kafka）方法不同，但核心逻辑一致：找对数据源、设好阈值、及时告警。
查 Redis 队列长度（Laravel/自建 Redis 队列适用）
Redis 是 Laravel 默认队列后端，high/default 等队列实际以 list 形式存在，键名通常是 queues:high（前缀受 HORIZON_PREFIX 影响）。它的长度最接近真实积压量：
- 直接执行：
redis-cli LLEN queues:high，返回整数即当前等待任务数 - 脚本化检测：每 20–30 秒运行一次，值 ≥ 80 就写日志或发钉钉/邮件
- 注意：比 Horizon 页面显示更实时，绕过了 Horizon 的 5 秒采样缓存
用 Horizon 看队列健康度（Laravel 专用）
Horizon 不只是看数字，它能反映“是否真卡住”：
- 访问
/horizon→ “Queues” 标签页 → 找 high 队列 → 看 Pending jobs - 点进去看详情：Jobs per minute 是否断崖下跌？Avg. 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 更可靠
