立刻知道死信队列消息堆积需主动监控其实时长度，如RabbitMQ须调用管理API获取messages值，结合连续3次30秒间隔均超5条的趋势判断，避免瞬时误报。
死信队列里消息堆积了，怎么立刻知道？
Python 本身没有内置的死信队列（DLQ）告警机制——它只是个语言，真正干活的是你用的 MQ（比如 RabbitMQ、Kafka 或 Redis）。告警必须由你主动轮询或监听 DLQ 状态来触发，不能靠 import 某个包就自动发钉钉。
常见错误现象：queue_declare 时设了 x-dead-letter-exchange，但没人查 dead_letter_queue 的长度；或者消费者 crash 后消息进 DLQ，日志里只留一行 basic.reject，没人看。
- 使用场景：RabbitMQ 最典型，Kafka 需自己建“dlq-topic”并写重试逻辑，Redis 则靠
lpush+ 定时扫描 - 关键动作不是“配置 DLQ”，而是“监控 DLQ 的
message_count” - 不要等凌晨三点被报警电话叫醒——把检查频率压到 30 秒以内，比写十遍重试逻辑都管用
RabbitMQ 死信队列长度怎么实时读？
得用 pika 连管理 API（/api/queues/%2F/dead_letter_queue），不是连 AMQP 端口。AMQP 协议本身不暴露队列深度，queue_declare 返回的 method.message_count 是声明时的快照，不是实时值。
示例要点：
立即学习“Python免费学习笔记（深入）”；
- HTTP 请求头带
Authorization: Basic base64(user:pass)，不是用pika.ConnectionParameters - 路径里的
%2F是 vhost 为/的编码，换成其他 vhost 要同步改 - 响应是 JSON，取
response['messages']，不是response['messages_ready']（后者不含未确认消息） - 别用
requests.get同步阻塞主流程——开个独立线程或用asyncio.to_thread调用
告警阈值设多少才不算误报？
设成 “大于 0” 就发告警？那网络抖动导致一次 basic.nack 就触发，运维会拉黑你写的脚本。
真实判断逻辑得带时间维度和变化趋势：
- 连续 3 次检查（间隔 30 秒）都 > 5 条，才触发 —— 排除瞬时积压
- 单次突增到 100+ 且前 5 分钟平均
- 如果 DLQ 里有
headers.x-death记录了重试次数，优先告警重试 ≥ 3 次的消息，别光数总数 - 注意 RabbitMQ 管理 API 的
messages字段包含未确认消息，而消费者实际卡住的往往在messages_unacknowledged
Python 发告警时最常漏掉的三件事
写完 requests.post 调钉钉/企微 Webhook 就以为完事？线上跑两天准出问题。
- 没设
timeout=(3, 7)—— Webhook 响应慢会拖垮整个健康检查线程 - 忽略 HTTP 429（Too Many Requests）—— 钉钉限流后返回空响应，你还以为发成功了
- 没记录原始 DLQ 数据（如
queue_name、message_count、timestamp）到本地日志 —— 出问题时连重放都做不到
复杂点不在代码多难写，而在你得同时盯住 MQ 状态、告警渠道稳定性、以及谁该在半夜三点接电话——这三块没对齐，告警就是聋子的耳朵。
