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对照现有工作流。重点看三个指标：定位根因时间、误重播率、历史模式识别能力。
差距在哪，可能就是下一个工具的机会。
热门跟贴