请求提供Azure Service Bus队列故障排查技术（Azure运维人员）

嘿，作为同样在Azure平台做应用支持的运维同行，我整理了一套实用的Azure Service Bus队列故障排查思路，帮你快速定位和解决问题：

• 队列核心指标检查：先打开队列的Overview页面，重点看Active Messages、Dead-Lettered Messages、Scheduled Messages这几个指标。如果活跃消息突然堆积，大概率是消费端出了问题；死信队列增长的话，基本是消息处理失败或者触发了规则限制。
• 资源配额验证：确认队列的Max Size有没有达到上限，还有单个消息的大小有没有超过限制（默认标准层256KB，高级层可到100MB）。配额耗尽的话，新消息会直接被拒绝。
• 错误指标分析：在Metrics页面查看Server Errors、Client Errors、Connection Counts这些指标，有没有突发的错误峰值。比如401错误可能是连接字符串权限不足，404可能是队列名或者命名空间写错了。

• 死信队列深度分析：如果有死信消息，一定要查看每条死信的Reason和DeadLetterErrorDescription字段，这俩是排查的黄金线索——比如是消息TTL超时、处理次数超过Max Delivery Count，还是消息格式不符合消费端要求。
• 消息内容验证：用门户的Peek Message功能查看可疑消息的内容，确认是不是payload格式错误、包含特殊字符，或者携带了超出预期的数据导致消费失败。
• 重试策略合理性检查：确认客户端应用的重试配置是否合理，SDK默认的重试是针对临时错误（比如网络波动），但如果是业务逻辑错误（比如依赖服务挂了），单纯重试只会让消息反复进入死信，得结合业务场景调整策略。

• 应用日志深挖：重点查看应用中与Service Bus交互的日志片段，有没有抛出MessagingException、TimeoutException这类异常。比如超时可能是网络延迟、客户端连接池耗尽，或者队列消息堆积导致消费速度跟不上。
• 连接字符串与权限验证：确认应用使用的连接字符串有没有对应队列的权限（比如Send/Listen/Manage），可以用Azure CLI命令快速核查：

  az servicebus queue authorization-rule list --namespace-name <你的命名空间名称> --queue-name <目标队列名称>
  

• SDK版本确认：如果用的是旧版SDK（比如.NET的Microsoft.Azure.ServiceBus），可能存在连接泄漏、消息丢失等已知bug，建议升级到最新的稳定版（比如Azure.Messaging.ServiceBus）。

• 防火墙与NSG规则检查：确认客户端所在网络有没有允许出站访问Service Bus的端口——默认是5671（AMQP协议）和443（HTTPS协议），如果用了高级层的专用端点，还要检查端点的连接状态和路由配置。
• Azure服务状态核查：可以在Azure门户的Azure Status页面查看对应区域的Service Bus服务状态，排除是不是Azure侧的区域性故障导致的问题。
• DNS与连接链路验证：如果客户端通过VPN或专用端点访问Service Bus，检查DNS解析是否正常，有没有路由跳错或者链路中断的情况。

如果以上步骤还没定位到问题，建议收集客户端详细日志、Azure门户导出的Metrics数据和死信消息的完整详情，提交Azure支持工单时附上这些信息，能大大加快问题排查的速度。

内容的提问来源于stack exchange，提问作者ATMK4MSFT