凌晨2点5000条死信：一个工程师的45分钟解法

5000条消息卡死信队列，排查要6小时——这不是能力问题，是工具问题。

一位Azure工程师把这套流程压到了45分钟。不是靠手速，是靠一个自研的开源工具。它把死信队列调试做成了"法医级"现场勘查。

凌晨2点的真实案发现场

监控告警炸响。死信队列（Dead-Letter Queue，DLQ）积压5000条。工程师需要立刻回答三个问题：哪些消息？为什么失败？要不要重播？

传统排查像考古：翻日志、对时间戳、猜关联。作者自述过去平均耗时6小时。现在45分钟收工——差距来自一个叫ServiceHub的工具。

它是开源、自托管的Web应用，核心假设很直接：死信队列调试就是法医调查，需要专门工具链。

五项能力，标准控制台给不了

ServiceHub做了五件事，Azure标准管理控制台做不到：

完整消息体检。点击任意消息（活跃或死信），直接看完整JSON、语法高亮、所有系统属性、代理错误原描述。不用导出、不用猜字段含义。

浏览器端智能聚类。用客户端AI把DLQ消息按错误模式分组，带置信度分数。关键：完全在浏览器运行，零数据外泄，不需要API密钥。

自动重播规则。定义条件、设置速率限制、加指数退避。引擎自主运行，实时显示Pending→Replayed→Success计数器。

30天DLQ情报库。每次扫描持久化到本地SQLite。今晚的 spike 是新事故还是上周二的老毛病，一查便知。

关联追踪器。粘贴任意关联ID（Correlation ID），跨队列、主题、命名空间一键追踪消息全路径。

整个设计只读。用PeekMessagesAsync——消费者零影响，Listen权限即可运行。

部署极简，安全自闭环

安装就一行命令：

git clone https://github.com/debdevops/servicehub.git
cd servicehub && ./run.sh

自动装.NET 10和Node.js。本地开http://localhost:3000。

不想装？30秒体验托管版：https://app-servicehub-prod.azurewebsites.net/

托管版用Microsoft Entra ID（Azure AD）认证。无用户数据库，不存个人数据，连接字符串AES-GCM加密存会话。

作者的原话：「What does your current DLQ investigation workflow look like? Drop it in the comments — I'm genuinely curious what the most painful part still is.」——他想知道大家的痛点在哪。

为什么这事值得技术人关注

ServiceHub不是个例，是一类需求的解法：云原生监控工具的"最后一公里"盲区。

Azure Service Bus、AWS SQS、RabbitMQ——这些消息中间件的标准控制台都卡在同一处：能看状态，难查因果；能读单条，难找模式；能手动重试，难自动化。

作者的路径很典型：6小时痛苦→自建工具→开源→MIT协议。GitHub地址：https://github.com/debdevops/servicehub，欢迎PR。

对25-40岁技术从业者，这工具的启示比功能更重要：

第一，客户端AI是隐私合规的捷径。模型跑在浏览器，绕过数据出境、API计费、合规审计三重麻烦。这种模式在敏感数据场景会越来越多。

第二，SQLite本地持久化是低成本情报系统。不用搭数据库，30天历史够覆盖大多数故障回溯需求。单机工具的"记忆能力"被低估了。

第三，只读设计是生产环境的底线。PeekMessagesAsync不碰消费者，Listen权限最小化——这是能进生产环境的通行证。

如果你也在用Azure Service Bus，或者任何有死信队列的消息系统，可以拿ServiceHub对照现有工作流。重点看三个指标：定位根因时间、误重播率、历史模式识别能力。

差距在哪，可能就是下一个工具的机会。