Microsoft AZ-400: 监控、可观察性与反馈 — 学习指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

属于 Microsoft DevOps Engineer Expert AZ-400 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

现代 DevOps 团队将监控、可观测性和反馈视为一个持续的循环，为工程、运营和产品决策提供信息。在 Azure 中，遥测数据从应用程序和基础设施流入 Azure Monitor 和 Log Analytics，并在其中进行查询、关联和可视化。分布式追踪将多个服务串联成端到端的事务，而警报和 on-call 集成则驱动快速修复。Azure DevOps 仪表板、工作项分析和实验通过将洞察反馈到规划和交付中，形成了闭环。本节深入探讨了如何设计一个集成的可观测性技术栈，以便在每个阶段都能提供可操作的反馈。

遥测、追踪与 Azure Monitor

Application Insights 是 Azure Monitor 的应用性能监控 (APM) 组件。通过以下方式添加检测（插桩）：

• SDK 和自动检测：.NET/.NET Core、Java、JavaScript、Node.js、Python，以及用于 .NET 和 Java 的 Application Insights Agent。使用连接字符串并设置 cloud_RoleName 来区分组件。
• 遥测初始化器和处理器：在遥测数据发出前添加或修改属性（例如 tenantId）并过滤 PII（个人身份信息）。
• 自定义遥测：使用 TrackEvent 跟踪业务操作，TrackMetric 跟踪数值型 KPI，TrackException 跟踪错误上下文，以及 TrackDependency 跟踪需要显式建模的外部调用。

遥测类型包括请求、依赖项 (HTTP、SQL、Azure SDK)、追踪、异常、页面视图、页面加载性能、可用性测试结果、自定义事件/指标以及实时指标。采样在保留信号的同时控制数据量和成本：SDK 自适应采样会按类型自动调整速率，以维持目标吞吐量和相关性；固定速率采样为合规性要求提供确定性采样。推荐使用 SDK 端采样，这样下游系统就永远不会处理被丢弃的数据项。保持粘性采样以确保端到端追踪的完整性。

分布式追踪提供端到端的事务可见性。Application Insights 实现了 W3C Trace-Context 标准 (traceparent/tracestate)，可自动跨 HTTP 传播相关性 ID；应跨异步边界和自定义协议传播上下文，以避免追踪链断裂。依赖项跟踪功能会自动收集常见的出站调用；对于消息队列的跳转或非标准 RPC，应发出自定义依赖项以补全调用图。App Map 和事务搜索功能可以可视化跨服务的流程、延迟和故障热点。为了实现前端到后端的关联，请启用 JavaScript SDK，并确保服务器端接受相关性标头，以便测量真实页面加载时间和用户旅程。

Azure Monitor 统一了平台和应用的遥测数据：

• 指标：多维度、近实时（一分钟或更精细的粒度）。使用带有静态或动态阈值的指标警报进行快速、低延迟的检测。
• 日志：存储在 Log Analytics 工作区中的半结构化遥测数据，可使用 KQL 进行查询以进行深度分析和异常探查。
• 警报：指标、日志和活动日志规则会路由到操作组。使用动态阈值、多资源目标和通用警报架构以实现一致的处理。
• 操作组：通过电子邮件/短信/语音、推送通知、webhook（包括 PagerDuty/OpsGenie）、ITSM 连接器、Logic Apps、Azure Functions 和 Automation runbook 进行修复。
• 诊断设置：配置每个 Azure 资源，将平台指标/日志流式传输到 Log Analytics、Azure Storage（用于归档）和 Event Hubs（用于 SIEM 引入）。通过策略驱动的部署确保一致性。

使用 Log Analytics (KQL) 进行查询和分析

Log Analytics 工作区是日志的查询和治理边界。按环境和数据主权进行规划：为生产与非生产环境分离工作区可以简化 RBAC 和保留策略；集中化则便于跨服务关联。数据源包括 Azure Diagnostics（平台日志/指标）、VM 代理（Syslog/Windows 事件、性能计数器）、Container Insights/AKS、Application Insights 组件日志（统一在 Azure Monitor Logs 下）、Azure AD 登录日志、通过引入 API 收集的自定义日志，以及用于精确流路由和转换的 Data Collection Rules。

Kusto 查询语言 (KQL) 专为时序和遥测分析而优化：

• 核心操作符：where (筛选)、project (选择)、extend (派生)、summarize by (聚合)、join/union (关联)、parse/parse_json (提取)、mv-expand (数组)、用于时间分桶的 make-series 和 bin，以及用于制图的 render。
• 常用模式：错误预算消耗（时间加权故障率）、p50/p95 延迟分布、依赖项异常值检测、请求成功率与流量对比，以及使用 series_decompose_anomalies 进行具备季节性感知的异常检测警报。
• 治理：已保存的查询和函数可促进重用；RBAC 和表级访问可限制对敏感数据集的访问。
• 跨资源和跨工作区：使用 workspace("workspaceNameOrId").Table 和 workspaces() 函数来合并跨环境和订阅的数据集；使用 resource() 进行跨资源联接。在大型联接上应用 let 绑定和 materialize() 来控制性能。

Azure DevOps 中的可视化与敏捷反馈

Azure DevOps 中的仪表板用于传达运营和流程的健康状况。团队级仪表板专注于团队的待办事项、迭代和在制品 (WIP)；项目级仪表板则呈现跨团队和项目组合的视图。小组件包括 Sprint 燃尽图 (Sprint Burndown)、燃起图 (Burnup)、速率 (Velocity)、累积流图 (Cumulative Flow Diagram, CFD)、周期时间 (Cycle Time)、前置时间 (Lead Time)、工作项图表/查询结果 (Work Item Chart/Query Results)、生成/发布摘要 (Build/Release summaries) 以及用于运行手册 (runbooks) 和 SLO 状态的 Markdown。通过仪表板权限保护小组件，并将查询范围严格限定在团队/区域，以避免跨团队信息泄露。

Boards 查询（通过查询生成器或 WIQL）为许多小组件提供支持。通过团队的区域路径/迭代对查询进行参数化以实现重用；在可用时，优先选择基于 Analytics 的小组件以获得更高的准确性和性能。关键流程指标：

• 周期时间 (Cycle time): 从“活动”（进行中）到“完成”所经过的时间；使用周期时间小组件来跟踪执行效率。
• 前置时间 (Lead time): 从创建/承诺到“完成”所经过的时间；反映了客户感知的系统总延迟。
• 吞吐量 (Throughput): 每个时间间隔内完成的项数；与在制品 (WIP) 策略进行比较以发现瓶颈。
• 累积流图 (Cumulative Flow Diagram): 可视化队列大小随时间按状态的变化；逐渐变宽的色带揭示了约束和上下文切换。 对于 sprint 跟踪，使用燃尽图 (Burndown)（剩余工作趋向于零的趋势）和燃起图 (Burnup)（总范围与已完成工作的对比，能适应范围变更）。速率 (Velocity) 报告每个 sprint 完成的平均工作量，并为容量规划提供信息；跨团队聚合时，仅聚合同类的估算单位。

当需要进行产品分析时，可将 Azure DevOps Analytics 连接到 Power BI，以融合交付指标与运营遥测数据（例如，前置时间与缺陷逃逸率），从而确定改进的优先级。

可靠性、告警与持续反馈

SLI/SLO/SLA 将可靠性确立为首要特性：

• SLI（服务级别指标）：用户体验的量化指标，例如，请求成功率、p95 延迟、关键端点的可用性或 UI 中的任务完成率。
• SLO（服务级别目标）：在某个时间窗口内的目标，例如，99.9% 的月度可用性或 p95 < 300 毫秒。将 SLO 与用户旅程（而非基础设施）挂钩。
• 错误预算：1 − SLO；用于管理发布风险、回滚标准和事件响应。使用 KQL 或指标告警，针对快速和慢速的预算消耗，实施消耗速率告警（例如，2 倍和 14 倍的预算消耗速率）。
• SLA（服务级别协议）：对客户的外部承诺；通常比 SLO 更宽松，并包含惩罚条款；它驱动但不强制规定工程护栏。

告警与待命：

• 对延迟敏感的条件使用指标告警；对复杂谓词（例如，多信号关联或异常分数）使用日志告警。
• 通过去重（告警处理规则）、动态阈值、严重性调整以及在计划内维护期间自动抑制来减少告警疲劳。
• 通过使用通用告警模式的操作组 Webhook，与 PagerDuty/OpsGenie 集成；映射告警关联键以实现事件去重，并为每个服务定义升级策略。
• 使用 Azure Automation runbooks、Functions 或 Logic Apps 自动化修复（例如，根据队列深度进行横向扩展、回收故障实例、切换功能标志）。将每个自动操作记录为 Application Insights 中的自定义事件，以保证可审计性。

持续反馈与实验：

• A/B 测试与灰度发布：使用 Azure Front Door 或 Traffic Manager 在边缘进行流量拆分，或使用 Azure App Configuration Feature Manager 实现基于单个用户或用户群组的功能标志发布。使用标志保护代码路径，并为每个变体收集事件遥测。
• 用户遥测：使用功能标志状态、用户属性（非 PII）和场景标识符发出 TrackEvent。在 Application Insights 中分析漏斗、用户流、留存率和群组表现，以验证假设。
• 功能使用情况分析：构建仪表板来跟踪 DAU/WAU/MAU、功能采用率和转化指标。将结果反馈到待办事项的优先级排序中。使用 Azure Pipelines 门禁，在预演环境 SLI 基线不达标或检测到实验 KPI 回归时，阻止生产部署。

实际问题场景

Spotify 需要为其部署在 Azure Kubernetes Service (AKS) 和 Azure App Service API 上的播客注入和播放服务提升端到端的可见性与反馈。事件发现延迟，且产品团队缺乏针对新播放功能的可信采用率指标。

1. 检测并关联应用程序遥测

• 将 Application Insights SDK 添加到 .NET 和 Node.js 服务中；在 Web 客户端上启用 Application Insights JavaScript SDK。配置 cloud_RoleName 和连接字符串；跨微服务和消息队列启用 W3C trace-context 传播。 原因：确保一致的关联 ID 和分布式追踪，以实现从浏览器到服务及其依赖项的完整事务可见性。

2. 将平台诊断数据流式传输到 Log Analytics

• 通过 Azure Policy 将诊断设置应用于所有 AKS 集群、App Service 计划、Application Gateway、Cosmos DB 和 Storage 帐户，将数据路由到一个集中的生产工作区，保留 90 天并归档到 Storage。 原因：保证平台日志/指标的统一覆盖，以便进行 KQL 关联和经济高效的长期保留。

3. 定义 SLI、SLO 和错误预算

• SLI：p95 API 延迟、请求成功率、注入管道吞吐量和播放器启动成功率。
• SLO：99.95% 的月度成功率、p95 播放启动延迟 < 300 毫秒、注入延迟 < 2 分钟。
• 创建基于 KQL 的错误预算消耗速率告警（快速/慢速）和带有动态阈值的延迟指标告警。 原因：将业务成果转化为可衡量、可操作的可靠性目标，并配备及时的告警。

4. 构建可操作的告警和待命集成

• 创建具有智能分组功能的 Azure Monitor 告警规则；路由到一个操作组，该操作组使用通用告警模式通过 Webhook 触发 PagerDuty。附加 Azure Automation runbooks，以根据队列深度自动扩展并重启不健康的 Pod。 原因：通过可靠的呼叫和安全、可审计的自动修复来降低 MTTA/MTTR。

5. 为工程和产品团队建立仪表板

• Azure DevOps 团队级仪表板：面向团队的周期时间（活动→完成）、交付周期（创建→完成）、CFD、速率和冲刺燃尽图。项目级仪表板：发布燃起图、跨团队吞吐量，以及通过 Markdown/Analytics 小组件展示的 SLO 状态。 原因：为团队提供执行洞察，同时为领导层提供项目组合和可靠性健康状况。

6. 实施实验和使用情况分析

• 使用 Azure App Configuration 功能标志逐步推出新的“智能跳过静音”功能。在需要时，使用 Front Door 规则在边缘拆分群组进行 A/B 测试。发出包含 featureFlagState、用户群组和结果指标的 TrackEvent。 原因：在安全验证影响的同时，捕获高保真度的用户遥测数据，以支持基于证据的决策。

7. 通过门禁强制执行发布质量

• 在 Azure Pipelines 中，添加门禁来查询 Application Insights/Log Analytics 中的预演环境 KPI（p95 延迟、失败率、实验变体表现）。如果基线或与 SLO 对齐的阈值未得到满足，则门禁失败。 原因：防止回归进入生产环境，并使部署决策与可靠性和产品 KPI 保持一致。

← 测试策略与质量工程 · 所有领域 · 包管理与工件管理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →