Azure Diagnostics

Azure Diagnostics 是什么

Azure Diagnostics 是 Microsoft 官方的 Azure 生产故障诊断入口，强调先分诊、后证据、再修复。它结合资源健康、AppLens、Azure Monitor、日志、指标与最近变更，覆盖 App Service、Container Apps、Functions、AKS、虚拟机、Event Hubs 和 Service Bus 等常见服务，而不是看到报错就直接重启或重建资源。

适用场景与选择边界

适合处理高 CPU、发布失败、冷启动、探针异常、镜像拉取失败、函数调用错误、Pod Pending、CrashLoop、节点异常、RDP 或 SSH 连接失败、AMQP 连接与消息锁问题。部署前就绪检查应使用 Azure Validate；架构准备和基础设施生成属于 Azure Prepare。

核心能力与工作机制

标准流程依次识别症状、检查 Azure 资源健康、阅读日志、分析指标并调查最近变更。能使用 AppLens 时优先获得服务特定诊断，再按资源类型加载专门指南。AKS、计算与消息服务都有独立路径，避免把 Web App 的经验套到 Kubernetes 或 Service Bus。

实际工作流

先确认受影响资源、订阅、区域、时间窗口和用户可见症状，再检查平台健康与资源健康。随后收集最小必要日志和指标，比较故障前后变化，形成一个可证伪的根因假设；只有证据支持时才执行低风险修复。每一步都记录发现、尝试、结果和回退方式。

输入、输出与交付物

输入包括资源标识、症状、开始时间、影响范围、最近发布或配置变更，以及按需授权的日志和指标访问。输出应是分诊摘要、证据、最可能根因、已排除假设、修复或缓解建议与验证结果，不应只给一串未经排序的命令。

依赖、账号与权限

通常需要 Azure 登录、目标订阅读取权限、Azure Monitor 或 App Insights 数据访问；AKS 还可能需要 kubectl 权限，虚拟机与消息服务需要相应诊断权限。日志可能含用户数据、连接信息和业务载荷，收集与分享时应最小化并脱敏。

限制与安全风险

生产环境的重启、扩缩容、密码重置、网络规则修改和节点操作可能扩大事故或破坏证据。诊断必须优先只读观察，并在变更前说明风险、回退和影响。日志命中时间上的相关性也不等于根因，需要结合指标、健康状态和变更记录交叉验证。

适合谁使用

适合 SRE、云运维、平台工程师和负责 Azure 应用的开发者，也适合事故处理中需要统一排查顺序的团队。完全不熟悉 Azure 的用户可从资源健康与时间线开始，避免一上来执行高风险命令。

上手与验收建议

准备资源 ID、时间范围、错误文本、影响比例和最近变更，先做只读快照。验收时确认问题是否可复现、核心指标是否恢复、错误率是否回落，并记录观察窗口；如果只是暂时消失但根因未明，应标记为缓解而不是解决。

来源、版本与许可

依据 microsoft/azure-skills 固定提交中的完整 Azure Diagnostics Skill、skills.sh 详情和 MIT 许可证整理。

常见问题

1. 诊断 Azure 故障的第一步是什么？

先明确症状和时间范围，再查看平台与资源健康，而不是立刻重启。这样可以先排除 Azure 区域或服务事件，也能保留事故现场，避免修复动作掩盖真正原因。

2. AppLens 与普通日志查询如何选择？

对支持的 Azure 服务，AppLens 可先提供服务特定的诊断视角；随后仍要用 Azure Monitor、应用日志和指标验证。没有 AppLens 时则按资源类型进入对应手册，不能停在通用建议。

3. 支持哪些 Azure 服务的故障排查？

来源明确覆盖 Container Apps、App Service、Function Apps、AKS、虚拟机计算，以及 Event Hubs 和 Service Bus 消息服务；每类服务都有不同的常见故障与参考路径。

4. AKS 的 CrashLoop 应按 Web 应用流程处理吗？

不应。AKS 事故会路由到专门指南，结合集群访问、节点、kube-system、调度、容器日志、探针、DNS 和升级状态排查，不能只看应用层 HTTP 日志。

5. 虚拟机连不上时会直接重置密码吗？

不会把重置凭据当默认第一步。应先判断 VM 运行状态、网络安全组、防火墙、路由、代理和 RDP 或 SSH 服务；密码重置属于有影响的动作，需要明确理由和授权。

6. 如何调查 Service Bus 消息锁丢失？

应结合 SDK 错误、AMQP 连接、处理时长、锁续期、网络状态和死信情况分析。只看到 lock lost 文本就扩大锁时长可能掩盖慢处理或连接中断，必须先建立时间线。

7. 诊断过程中可以修改生产资源吗？

可以在证据充分且用户授权时采取修复，但默认顺序是只读观察、形成假设、评估影响与回退，再执行最小变更。重启、扩缩容、网络与身份修改都不能被当成无风险查询。

8. 最终诊断报告应该包含什么？

应记录症状、影响、时间线、资源健康、关键日志和指标、最近变更、尝试过的措施、结果、最可能根因以及后续防复发行动，便于复核而不是只留下命令历史。