Microsoft AZ-204: Azure 监视、诊断与 DevOps 集成 — 学习指南

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Azure Monitor 数据、KQL 以及使用操作组的警报

Azure Monitor 处理两种主要数据类型：指标和日志。指标是轻量级的数字时间序列，支持近实时引入和多维切片（例如，按实例、API 路由）。它们最适合用于快速检测（CPU、内存、请求速率、延迟、可用性），并且默认支持长达 93 天的保留期。日志是结构化的、可查询的记录，存储在 Log Analytics 工作区中，包括 Application Insights 数据、平台资源日志以及保留期可配置的自定义日志。使用“诊断设置”可将平台指标和资源日志路由到工作区、Event Hub 或 Storage，以进行存档和分析。

Kusto 查询语言 (KQL) 为探索性分析、仪表板和日志警报提供支持。核心模式包括：

基本查询：使用 Table | take 10 进行快速采样；为保证性能，务必尽早使用 where TimeGenerated >= ago(…) 来限制时间范围。
筛选和投影：使用 Table | where Column == "Value" | project KeyColumns 来减少负载并聚焦分析。
聚合：使用 summarize count() by bin(TimeGenerated, 5m), Dimension 来计算速率、百分位数或平均值；使用 percentile() 和 make-series 创建时间图表。
联接：在 operation_Id 等关联键上使用 join kind=inner 或 leftouter 来连接 Requests 与 Dependencies 或 Exceptions；对于跨资源联接，请确保两者都发送到同一工作区或启用跨资源查询。
有用的表：requests、dependencies、exceptions、traces、availabilityResults 用于 Application Insights；AzureDiagnostics 和 AzureActivity 用于平台日志；Perf 和 Heartbeat 用于 VM insights。
最佳实践：仅投影所需列，尽早筛选，按合理的时间间隔分箱 (bin)，并避免在非必要时对大时间窗口进行开销高昂的交叉联接。

警报涵盖指标和日志。指标警报近实时地评估指标阈值，支持维度和按维度拆分，并可使用静态或动态阈值（基于 ML 的基线）。它们是状态化的，可根据评估结果触发和自动解决，并在状态更改时产生一次通知。日志（计划查询）警报按设定的频率运行 KQL，并根据查询结果（匹配项数量或度量阈值）触发。当条件依赖于跨表的复杂模式或需要文本分析时，请使用日志警报。Application Insights 中的智能检测和异常警报可以在没有明确阈值的情况下高亮显示性能衰退。

操作组为警报定义了可重用的响应集。通知类型包括电子邮件、SMS、语音和 Azure 移动应用推送。集成包括：

Webhook（v1 和 v2），使用通用警报架构 (Common Alert Schema) 以获得一致的负载；设置自定义标头进行身份验证，并路由到事件系统（例如 PagerDuty 或自定义接收器）。
Azure Functions、Logic Apps 和 Automation runbook，用于以编程方式进行修复和扩充；使用 Logic Apps 实现灵活的转换和连接器。
ITSM 连接器（例如 ServiceNow），用于创建带有映射字段的事件。将操作组与警报处理规则配对，以便在维护期间抑制警报、按严重性路由或应用动态操作。为确保出站 webhook 的安全，请将接收方限制为 Azure IP，或要求签名/标头，并验证通用警报架构 (Common Alert Schema) 的属性，例如 Essentials.AlertRule 和 AlertContext。

用于可监控性和可重复部署的 ARM 模板

Azure Resource Manager (ARM) 模板以代码形式声明式地定义资源和监控配置。模板的结构包括：

$schema 和 contentVersion 用于标识模板版本。
parameters 用于外部化值（例如，工作区名称、位置、SKU）。对机密信息使用 secureString/secureObject。
variables 用于计算值，以避免重复。
resources 用于声明式部署 Application Insights、Log Analytics 工作区、警报规则、操作组和诊断设置。
outputs 用于为下游部署阶段输出值，例如 Application Insights connectionString。

使用链接模板或嵌套模板来组合复杂的部署。部署资源 (Microsoft.Resources/deployments) 通过 templateLink（外部 URI）引用子模板，或将其内联嵌入。通过 parameters 或 parametersLink 传递参数对象，定义 dependsOn 以确定顺序，并在不同环境中重用模块。通过 ARM 实现默认可监控性的示例：

部署一个 Log Analytics 工作区并设置 workspaceResourceId 输出，供 Application Insights 资源使用（基于工作区的模式）。
创建 Application Insights（基于工作区）并输出其 connectionString；避免暴露旧版的检测密钥（instrumentation keys）。
在资源（例如 App Service、Key Vault、Storage）上启用诊断设置（Diagnostic settings），以将日志和指标流式传输到工作区和/或 Event Hub。
预配带有条件和维度的指标警报（microsoft.insights/metricAlerts），以及带有 KQL 的计划查询警报（microsoft.insights/scheduledQueryRules），通过资源 ID 链接操作组。
定义带有电子邮件/短信和 webhook 接收器的操作组（microsoft.insights/actionGroups）；将地址和端点参数化，以实现特定于环境的路由。

采用条件（conditions）和复制循环（copy loops）来实现可扩展的部署（例如，将诊断设置应用于一组资源 ID）。使用 resourceId、subscriptionResourceId、reference、concat 和 guid 等 ARM 函数来构建动态引用和稳定的名称。通过在 ARM 或 App Service 配置资源交付的应用设置中集中管理角色名称约定和采样，保持跨服务的遥测配置一致。

实际问题场景

Adobe 需要为其构建在 Azure App Service API 和 AKS 微服务上的新型多区域媒体处理管道实现端到端的可观测性。他们要求能够快速检测延迟衰退、实现跨服务的分布式追踪、对公共端点进行主动可用性检查，并通过基础设施即代码（infrastructure-as-code）的可重复性，将事件自动路由到其待命系统。

使用连接字符串通过 Application Insights 检测服务

配置每个 App Service 和 AKS 工作负载使用 Application Insights 连接字符串（connection string）而非旧版密钥，以确保正确的引入端点和面向未来的路由。为每个服务设置云角色名称（cloud role names），以便进行清晰的筛选和映射。在核心 API 中选择基于 SDK 的检测来发出领域事件和指标；为辅助服务启用无代码附加（codeless attach）以加速覆盖范围。原因：连接字符串提供了端点灵活性；SDK 提供自定义遥测，而无代码附加则降低了采用成本。

启用分布式追踪和依赖项跟踪

确保出站 HTTP 客户端和 Azure SDK 传播 W3C 跟踪上下文；在 KQL 中验证 operation_Id 的连续性。对于后台消息流（Service Bus），确认相关性已由 SDK 注入和提取；在使用自定义标头的地方，使用 TelemetryInitializers 进行补充。原因：一致的跟踪传播可以在微服务之间实现准确的端到端延迟和故障归因。

实施可用性测试和自定义综合检查

从多个地理位置为公共 API 配置 URL ping 测试，并在一个轻量级的健康端点上进行内容匹配。对于需要身份验证的流程（令牌获取和媒体提交），实施一个综合客户端来调用工作流，并发出带有运行位置和详细消息的 TrackAvailability 结果。原因：URL ping 提供快速的外部验证；TrackAvailability 支持超出基本 ping 范围的、需要身份验证的复杂业务流程。

在 Log Analytics 工作区中集中数据并路由平台日志

部署一个工作区，并在 App Services、AKS 控制平面日志、Key Vault 和 Storage 上配置诊断设置（Diagnostic settings），以将日志和指标流式传输到该工作区。确保 Application Insights 资源是基于工作区的，以统一查询。原因：单一工作区支持跨服务的 KQL 查询，可以将请求、依赖项和平台日志连接起来进行整体调查。

使用操作组创建指标和日志警报

根据请求持续时间的百分位数和按位置划分的可用性定义指标警报，使用动态阈值，并按云角色名称（cloud role name）进行拆分。添加计划查询警报，按操作名称检测错误峰值，并使用基于 operation_Id 的 KQL join 将其与依赖项故障相关联。原因：指标警报提供近乎实时的检测；日志警报可以捕获无法用简单阈值表达的复杂模式。

通过操作组和 webhook 集成事件响应

配置一个操作组，其中包含发送给服务所有者的电子邮件、发送给待命负责人的短信，以及一个使用通用警报架构（Common Alert Schema）连接到 Adobe 事件平台的安全 webhook。添加一个 Logic App 接收器，用最近的 KQL 查询结果和拓扑元数据来丰富负载（payload）。原因：多渠道通知可以减少 MTTA；webhook 和 Logic App 可以实现自动化工单创建和内容丰富的事件。

使用 ARM 模板将监控代码化

编写 ARM 模板来部署 Log Analytics 工作区、Application Insights（基于工作区）、诊断设置、指标警报、计划查询警报和操作组。将环境名称、区域和联系点参数化；输出 Application Insights connectionString 以供下游应用配置使用。为团队拥有的模块（平台 vs. 应用）使用链接模板。原因：基础设施即代码（Infrastructure-as-code）确保了在开发、预演和生产环境中一致、可重复的可观测性，并支持 CI/CD。