1. 课程导入与可观测性全景

在生产环境中，系统出问题几乎是必然事件。真正决定故障处理效率的，不是“有没有监控”，而是当告警响起时，你能否在几分钟内回答三个问题：哪里坏了、为什么坏、影响多大。Azure 可观测性体系正是围绕这三个问题构建的，它由三大支柱组成——指标（Metrics）、日志（Logs）、追踪（Traces）。理解它们各自擅长回答什么问题、彼此如何关联，是后续所有故障诊断工作的基础。

三大支柱分别“看见”什么

指标是随时间变化的数值序列，特点是轻量、高频、聚合。例如 Azure Monitor 中虚拟机的 Percentage CPU、App Service 的 Http5xx、SQL Database 的 DTU consumption percent，都是按分钟甚至秒级采集的数值。指标最擅长回答“是否异常、异常持续多久、趋势如何”，适合做告警和容量判断，但它通常不携带请求级别的上下文，无法直接告诉你“是哪个用户、哪条 SQL 导致的”。

日志是离散的事件记录，带有时间戳和结构化字段。Application Insights 的 traces、requests、exceptions 表，以及 Log Analytics 工作区中的各类表，都属于日志范畴。日志擅长回答“发生了什么、具体错误信息是什么、涉及哪些字段”。它信息丰富但体量大，查询成本高，因此更适合在指标告警之后做“下钻定位”。

追踪描述一次请求在分布式系统中的完整调用路径。在 Application Insights 中，一次请求会生成一个 operation_Id，其下挂载多个依赖调用（如 HTTP、SQL、Service Bus），每个环节都有耗时和状态。追踪擅长回答“慢在哪一跳、哪次调用失败、跨服务链路如何”，是微服务架构下定位性能瓶颈和级联故障的关键。

三者的关系：从“发现”到“定位”的漏斗

三大支柱不是并列孤立的，而是构成一条由粗到细的诊断漏斗。指标负责发现异常，日志负责确认细节，追踪负责还原链路。它们通过共享的关联字段（如 operation_Id、cloud_RoleName、资源 ID、时间戳）互相跳转。例如，当某 App Service 的 Http5xx 指标突增时，你可以从指标图表直接跳转到相关日志查询，再通过 operation_Id 打开端到端事务视图，查看具体是哪一次依赖调用超时。

生产故障诊断的核心目标

生产故障诊断的目标可以概括为四个层次，按优先级递进：止损、定位、根因、预防。止损是第一优先级——先恢复业务，例如回滚部署、扩容实例、切换流量；定位是找到出问题的组件或依赖；根因是解释“为什么这个组件会出问题”；预防则是把结论转化为告警规则、容量规划或代码修复。很多初学者一上来就追求根因，结果业务中断时间被拉长，这是需要避免的。

在 Azure 中，这四个层次都有对应的工具支撑：止损依赖指标告警和自动缩放；定位依赖日志查询和追踪视图；根因分析依赖 Application Insights 的失败分析、依赖图和 Profiler；预防则依赖 Azure Monitor 告警规则、Workbook 和 Azure Advisor 建议。

学习路径：从单点到链路

本课程后续章节将按“由浅入深、由单资源到分布式”的顺序展开。建议的学习路径如下：

• 基础层：掌握 Azure Monitor 数据平台、指标资源管理器、Log Analytics 工作区与 KQL 基础查询。
• 应用层：接入 Application Insights，理解 requests、dependencies、exceptions、traces 四张核心表，学会用 operation_Id 串联一次请求。
• 诊断层：掌握告警规则设计、动态阈值、行动组配置，以及从告警到日志再到追踪的下钻路径。
• 进阶层：分布式追踪、依赖图分析、Profiler 与 Snapshot Debugger、容器与 AKS 可观测性。
• 实战层：典型故障场景复盘，如 HTTP 5xx 突增、SQL 依赖超时、内存泄漏、消息积压。

一个最小可用的诊断示例

假设某电商应用的结账接口在 14:05 出现响应变慢。你可以按以下顺序操作（示例参数为教学假设）：

-- 第一步：在 Log Analytics 中查看近 30 分钟请求耗时分布
requests
| where timestamp > ago(30m)
| where name == "POST /api/checkout"
| summarize avg(duration), percentile(duration, 95), count() by bin(timestamp, 5m)
| order by timestamp desc

-- 第二步：找出耗时最高的 operation_Id
requests
| where timestamp > ago(30m) and name == "POST /api/checkout"
| top 5 by duration desc
| project timestamp, operation_Id, duration, resultCode

-- 第三步：用 operation_Id 查看该请求的依赖调用
dependencies
| where operation_Id == "<上一步得到的 Id>"
| project timestamp, name, type, target, duration, success
| order by timestamp asc

如果第三步显示某条 type == "SQL" 的依赖耗时 3200ms 且 success == false，而其他依赖都在 50ms 以内，那么根因方向就收敛到数据库层。接下来可以结合 SQL Database 的 DTU consumption percent 指标和 AzureDiagnostics 日志进一步确认是慢查询还是连接池耗尽。这个“指标发现 → 日志过滤 → 追踪定位”的三步路径，就是本课程反复训练的核心动作。

掌握三大支柱的分工与协作，你就拥有了生产故障诊断的“地图”。后续每一章都会在这张地图上填充具体的工具、查询和判断方法，最终形成一套可复用的诊断能力。