Microsoft AZ-104: Azure Monitor、备份和站点恢复 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

概述

Azure 上的卓越运营需要三大支柱协同工作：可观测的遥测数据、可恢复的数据和弹性的连续性计划。Azure Monitor 及其 Log Analytics 基础可收集高保真指标和日志，驱动智能警报，并呈现应用程序性能。Azure Backup 通过策略驱动、基于保管库的恢复来保护平台和 IaaS 数据，其中包括可实现最短停机时间的即时还原功能。Azure Site Recovery (ASR) 将工作负载复制到备用站点，并编排故障转移和故障恢复，以满足业务的 RPO/RTO 要求。补充性服务——用于网络诊断的 Network Watcher 和用于平台感知的 Azure Service Health——共同构成了一套完整的管理员工具包。

Azure Monitor and Log Analytics

Azure Monitor 统一了平台指标和日志。指标是为近实时分析而优化的数字时间序列（高基数、多维度，对大多数资源而言具有一分钟的粒度）。使用 Metrics Explorer 进行可视化，并通过静态或动态阈值设置近实时指标警报。日志是存储在 Log Analytics 工作区中的富架构记录，可使用 Kusto 查询语言 (KQL) 进行查询，用于调查、仪表板和计划（日志）警报。

诊断设置是连接资源与遥测接收器的桥梁。在每个 Azure 资源上，配置诊断设置以选择类别（平台指标、平台日志和资源日志），并将其路由到一个或多个目标：

• Log Analytics 工作区，用于分析和基于日志的警报
• 存储帐户，用于长期、低成本的保留和合规性
• Event Hubs，用于流式传输到 SIEM 或第三方工具

审慎设计 Log Analytics 工作区：

• 工作区范围和访问权限：在工作区和表级别使用 RBAC，以符合最小权限原则和运营边界（例如，按环境和区域划分）。资源上下文查询允许团队查询他们有权访问的资源范围内的日志，即使日志是集中存储的。
• 数据收集：优先使用带有数据收集规则 (DCR) 的 Azure Monitor agent (AMA)，而不是旧版代理。DCR 定义了要收集的内容（性能计数器、Windows/Linux 事件日志、syslog、自定义文本日志）、从哪些计算机收集以及收集到哪些表中，从而实现按范围划分的精细化管道。
• 成本和保留：通过按表设置保留期、存档和在适当情况下使用基本日志来控制成本。尽可能在收集时使用采样和筛选。
• 数据源：Azure Activity Log、通过诊断设置收集的资源日志、VM insights 和 Container insights、Azure AD 登录和审核日志（通过诊断设置）、Azure Firewall/NSG 流日志、自定义应用程序日志，以及通过 Azure Monitor agent 收集的本地数据。

精通 KQL 至关重要。示例：

• 快速审计：

undefined

• 性能分类：

undefined

• 错误率：

undefined

操作组定义了响应警报的人员和方式：电子邮件/短信/推送/语音、安全 Webhook、ITSM 连接器、Functions、Logic Apps 和 Automation runbook。在多个警报规则中重用操作组，并强制执行一致的事件路由。

Azure Monitor 支持多种警报类型：

• 指标警报：以近实时频率评估平台或自定义指标，可使用静态阈值或能够学习正常基线的动态阈值。
• 日志（计划查询）警报：按配置的频率在工作区数据上运行 KQL；根据结果计数或数值聚合触发。适用于跨资源的复杂模式。
• 活动日志警报：在控制平面事件（例如，删除 VM 或更改角色分配时）上触发。这些警报不需要工作区。
• 智能检测：主要针对 Application Insights 资源的异常检测和故障率峰值；自动通知所有者并可与操作组集成。

Application Insights and Alerting

Application Insights 通过检测代码和平台来提供端到端的应用程序遥测。使用连接字符串和一流的 SDK（.NET、Java、Node.js、Python）或 OpenTelemetry 进行供应商中立的跟踪。对于 PaaS 服务（App Service、Functions、AKS），在可用时启用自动检测，以在无需更改代码的情况下捕获请求、依赖项、异常和跟踪。维护分布式跟踪上下文，以关联客户端、API 和后端跃点。

关键遥测类型：

• 请求：包含响应代码和持续时间的传入操作
• 依赖项：包含持续时间和成功状态的出站调用（HTTP、SQL、队列）
• 异常和跟踪：包含严重性级别的错误和诊断日志
• 指标：自定义或标准计数器
• 页面视图和浏览器计时：前端性能
• 自定义事件和度量：特定于域的信号

应用自适应采样来控制引入量而又不失信号保真度，并在事件期间使用 Live Metrics Stream 获取低延迟的洞察。

可用性测试验证外部可达性和 SLA：

• 标准（URL ping）测试：从多个 Azure 区域探测端点，验证状态代码、SSL 过期窗口、内容匹配和响应时间阈值。
• 自定义测试：在代码中使用 TrackAvailability 来实现综合工作流或受保护的端点。 故障可以自动生成连接到操作组的警报。

通过 Application Insights 中的智能检测来增强警报功能：

• 故障异常和性能下降
• 内存泄漏和依赖项异常 这些功能可以学习典型模式并减少误报，从而对基于阈值的警报形成补充。

Azure Backup

恢复服务保管库是备份管理、策略和恢复的核心。应将保管库放置在与受保护资源相同的区域中（或者，对于服务支持的跨区域还原场景，则放置在配对区域中）。通过软删除、清除保护和针对关键操作的多用户授权来强化保管库的安全性。

备份策略定义了计划和保留期：

• Azure VM 备份：每日快照提供短期保留，可选的每周/每月/每年长期保留；启用后，通过 VSS (Windows) 或前/后脚本 (Linux) 实现应用程序一致性的恢复点。
• Azure Files 备份：由共享快照支持的每日备份；根据业务需求设定保留期；支持还原到原始共享或备用共享，并可进行项级恢复。
• Azure VM 中的 SQL Server：完整备份（每日/每周）、差异备份（每日）和日志备份（频率可低至每 15 分钟一次）可实现时间点还原。自动保护功能可发现新数据库。

即时还原功能通过使用本地存储的快照来加速 VM 恢复，这些快照在存入保管库的深层存储之前会短期保留。管理员可以：

• 还原整个 VM（作为新的计算实例）以最大限度地缩短恢复时间
• 还原磁盘并将其重新附加到现有 VM 以进行定向修复
• 通过将恢复点作为临时 iSCSI 设备装载到订阅中任何（有角色权限的）VM 上来执行文件和文件夹恢复，从而能够在勒索软件等事件后进行精准还原

VM 备份的注意事项包括针对非关键数据的磁盘排除、加密处理（Azure Backup 支持加密磁盘）以及一致性模型（崩溃一致性与应用程序一致性）。Azure Files 备份利用存储快照，受益于增量、空间高效的保留策略和软删除保护。Azure VM 中的 SQL 备份使用一个由保管库协调的、感知工作负载的扩展，以在 Always On 可用性组和独立实例中生成合规、可还原的备份链。

Azure Site Recovery、Network Watcher 和 Service Health

ASR 提供工作负载复制和编排式恢复：

• 复制源：从本地 VMware/Hyper-V/物理机到 Azure；Azure 区域到区域。受保护计算机上的 Mobility 服务会捕获变更并将其复制到缓存/目标存储。为共享写入顺序的分层应用启用多磁盘一致性。
• 目标配置：预先创建或映射资源组、VNet/子网、可用性选项（区域/集）、托管磁盘类型和命名约定。使用网络映射和 DNS 更新来确保故障转移后的可达性。
• 故障转移选项：测试故障转移（隔离验证，不影响生产环境）、计划内故障转移（源端关闭，无数据丢失）和计划外故障转移（中断期间尽力而为）。故障转移后，执行“重新保护”以反向复制；当主站点就绪时，根据源的不同，通过进程服务器或直接复制进行“故障恢复”。
• 恢复计划：通过组、手动批准步骤以及 Azure Automation runbook 或脚本（用于应用预热、负载均衡器重新配置和 DNS 更改）来编排多虚拟机层。嵌入排序和超时以实现可预测的 RTO。

RPO/RTO 目标指导策略制定：

• RPO（可接受的数据丢失量）由变更率、网络吞吐量和复制频率驱动。设置 RPO 阈值，以便在超出时触发运行状况警报。
• RTO（服务恢复时间）取决于启动时间、编排步骤、DNS/连接更新以及数据平面操作（磁盘附加）。调整恢复计划、预先预配容量，并使用测试故障转移来验证是否满足目标。
• 复制策略定义了应用一致性快照的频率和恢复点保留窗口，以平衡存储成本、恢复灵活性和性能。

Azure Network Watcher 为管理员提供精确的网络诊断工具：

• IP 流验证：验证某个流是被 NIC 上的有效 NSG 规则允许还是拒绝，并识别出影响决策的具体规则。
• 下一跃点：计算到给定目的地（互联网、虚拟网络、虚拟设备）的路由决策，揭示有效的用户定义路由和系统路由。
• 连接故障排除：在源和目标之间跨 VNet 和混合链接执行端到端探测，报告可达性、延迟以及发生故障的跃点。
• 数据包捕获：在 VM NIC 上使用筛选器（协议/端口/IP）捕获数据包，并存储到存储帐户或本地，可用于对间歇性问题进行深度检查。需要在 VM 上安装 Network Watcher 扩展。

Azure Service Health 通过平台感知能力来补充监控：

• 服务问题：影响所选服务和区域的实时中断和降级事件，提供根本原因和缓解措施更新。
• 计划内维护：关于可能影响工作负载的即将到来的平台维护窗口的通知，包含时间表和所需操作。
• 运行状况建议：可能需要更改配置的最佳实践和安全建议。 创建范围限定于服务/区域/订阅的 Service Health 警报，并通过操作组进行路由，以便运营团队在受到影响前得到通知。使用 Resource Health 查看每个资源的可用性状态（可用、已降级、不可用、未知），以区分平台问题和工作负载问题。

实际问题场景

Adobe 必须加固并投入运营一个新的双区域 Azure 电子商务平台，满足严格的可观测性、备份和灾难恢复目标，同时确保快速的网络故障排除和平台感知能力。

1. 每个区域部署一个中央 Log Analytics 工作区，并将数据收集规则 (DCR) 附加到所有 VM 和 AKS 节点，以通过诊断设置收集性能、syslog/EventLog 和特定于资源的日志。 原因：区域性工作区可保护数据驻留和性能；AMA+DCR 提供精细、可扩展的收集和成本控制。

2. 在 App Service、Key Vault、Azure Firewall、Application Gateway 和 Storage 上配置诊断设置，将日志和指标路由到区域工作区，并路由到存储帐户以进行长期保留。 原因：集中式分析可实现跨资源关联分析；存储保留满足合规性和取证需求。

3. 使用 OpenTelemetry 检测 Web 和 API 层，并在 App Service 上启用自动检测。从至少五个 Azure 区域创建可用性测试，并进行内容匹配和 TLS 到期检查。 原因：深度分布式追踪和综合测试能在客户发现问题之前，检测到影响用户的回归。

4. 创建 Azure Monitor 警报：

• 针对 CPU、内存、HTTP 5xx 错误率和 App Gateway 后端运行状况的动态指标警报
• 使用 KQL 针对异常防火墙拒绝和失败登录的计划查询警报
• 针对关键资源上的删除/角色分配事件的活动日志警报
• 将所有警报连接到共享操作组（通过电子邮件/短信通知待命人员，通过 webhook 连接到 ITSM，通过 Logic App 创建事件单） 原因：多信号警报通过将警报路由到正确的人员和系统，缩短了平均检测时间 (MTTD)。

5. 使用 Azure Backup 保护数据：

• 启用 VM 备份，策略与夜间备份和长期保留对齐；在适用时启用应用一致性快照
• 通过每日备份和软删除保护托管媒体资产的 Azure Files 文件共享
• 通过完整/差异/日志备份计划保护 Azure VM 中的 SQL Server，以支持时间点还原
• 通过在预演环境中执行文件级还原来验证即时还原功能 原因：基于保管库的备份和即时还原可最大限度地减少 IaaS 和文件工作负载的停机时间和数据丢失。

6. 为 Web、API 和 SQL 层实施 Azure Site Recovery 以实现区域到区域的灾难恢复 (DR)，复制策略的目标是低 RPO 和每小时的应用一致性恢复点。构建一个分层（首先是数据层，然后是 API 层，最后是 Web 层）的恢复计划，包含更新 DNS 和清除 CDN 缓存的自动化，并每季度在隔离的 VNet 上进行测试故障转移。 原因：ASR 复制和恢复计划通过编排式、可审计的 runbook 和无中断测试，提供可预测的 RTO。

7. 启用 Network Watcher，并使用“连接故障排除”来验证前端到后端的流，使用“下一跃点”来验证通过 NVA 层的 UDR，使用“IP 流验证”来确认 NSG 加固。在 API VM 上配置按需数据包捕获，用于间歇性超时分析。 原因：专用诊断工具可快速隔离路由/NSG 问题，并在需要时提供数据包级别的证据。

8. 为范围内的两个区域和服务（App Service、SQL、Storage、Key Vault、Front Door）创建 Azure Service Health 警报。将警报路由到相同的操作组，并为计划内维护建议添加领导层通讯组列表。 原因：主动感知平台事件和维护可防止意外中断，并实现协调沟通。

这种集成方法确保 Adobe 能够满足其 RPO/RTO 目标，从勒索软件或操作员错误中快速恢复，在几分钟内检测和修复异常，并能够最终确定地对网络路径进行故障排除，同时随时了解 Azure 平台事件。

← Azure 数据库和数据服务 · 所有领域 · Azure 安全和合规性 →

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

浏览 Microsoft →