Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Monitor Logs是一种集中式软件即服务（SaaS）平台，用于通过Azure和非Azure资源和应用程序收集、分析和处理系统生成的数据。
使用 Azure 时，可靠性是共同的责任。 Azure提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
Azure Monitor日志提供内置的复原功能，可保护数据并最大程度地减少中断。 本文介绍这些功能以及如何使用这些功能使Log Analytics工作区能够灵活应对各种潜在的中断和问题，包括暂时性故障、可用性区域中断和区域中断。
生产部署建议
Azure Monitor日志提供了多种功能，你可以使用这些功能单独或组合使用，以帮助增强工作区对各种类型的问题的复原能力。
| 能力 | 说明 | 成本影响 |
|---|---|---|
| 可用性区域 | 通过区域中区域之间的冗余保护Log Analytics工作区免受数据中心故障的影响。 | 不收取额外费用。 包含在标准工作区定价中。 专用群集必须满足承诺层最低要求。 |
| 数据导出 | 通过将日志连续导出到异地冗余存储帐户，针对整个区域故障备份引入的日志。 | 存储成本因卷和冗余层（GRS）而异。 导出本身不收取额外的Azure Monitor费用。 |
有关详细的定价信息，请参阅 Azure Monitor 定价。
某些Log Analytics功能与所有可靠性功能不兼容。 在工作区复制功能中，辅助表是不被支持的。 有关功能兼容性的详细信息，请参阅 Log Analytics 的可靠性最佳做法。
可靠性体系结构概述
本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。
逻辑体系结构
使用 Azure Monitor 日志时，部署 Log Analytics 工作区，这是可以收集任何类型的日志数据的数据存储。
Log Analytics工作区与 cluster 相关联，后者为工作区和其他功能提供计算资源。 大多数工作区在共享群集上运行，这些群集Azure部署和管理，并在多个客户之间共享。 可以选择部署 专用群集，该群集为工作区提供专用资源。 共享群集和专用群集之间的可靠性功能存在一些差异，本文对此进行了介绍。
Azure Monitor日志具有两个不同的数据路径，每个路径都有其自己的可靠性特征：
引入是日志数据流入Log Analytics工作区的路径。 Azure Monitor服务仅在将数据持久写入存储后才确认收到数据。 引入路径包括多个组件：
数据源 生成遥测数据。 某些源（如通过诊断设置发送的Azure平台日志）通过
诊断设置0 将数据直接提交到 Azure Monitor 服务。 其他源需要 代理 来收集和转发数据。 应用程序还可以使用 Logs 引入 API将日志直接发送到Azure Monitor。 数据收集规则（DCR） 定义要收集的数据、如何转换数据以及发送数据的位置。 DCR 通过数据收集端点 (DCE) 将数据路由到 Azure Monitor 服务。
查询 是检索和分析已存储在工作区中的数据的路径。 日志查询使用 Kusto 查询语言（KQL），并针对工作区的存储数据运行。
引入和查询作为不同的服务操作进行处理，因此对一个的中断不一定影响另一个服务操作。 例如，在数据摄取性能下降的过程中，您可能仍然能够查询之前摄取的数据。 同样，查询端问题不会阻止引入和存储新数据。
有关Azure Monitor日志的核心组件的详细信息，请参阅 Azure Monitor 日志概述。
物理体系结构
在内部，Azure Monitor 日志对日志数据的计算和存储组件分别使用多个副本。 这些副本由Azure管理，无需配置或管理它们。
你负责部署和管理代理，以及运行代理的计算资源的可靠性。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
请考虑Azure Monitor日志中的以下暂时性故障类型：
Azure Monitor 服务中的瞬态故障：Azure Monitor 服务在从摄取过程中删除之前，验证工作区中的每个日志记录是否已成功摄取。 如果数据摄取不可用或限制请求速率，诊断设置和 Azure Monitor 代理会开始在本地缓冲数据，并使用指数退避策略重试数小时。 相比之下，提交引入请求或查询的自定义应用程序必须实现其自己的重试逻辑。
影响数据摄取连接的暂时性故障： 代理和 Azure 诊断设置会在本地缓冲数据，并在摄取终结点暂时不可用时重试传输，这使得摄取路径对暂时性故障更加具备弹性。
影响自定义应用程序日志记录的暂时性故障： 若要验证自定义应用程序是否正确处理暂时性错误，请监视以下指标：
- 引入延迟
- 失败的摄取计数
- 导出失败
- 查询失败率
如果看到持续引入延迟超过 5 分钟，则可能表示存在更重要的非暂时性问题。 查看本文档其他部分中的指南，了解如何抵御其他故障类型。
查询和其他操作期间的暂时性故障： 如果在查询期间或执行其他操作时发生暂时性故障，则客户端负责重试。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上分开的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
Azure Monitor日志提供两种类型的可用性区域支持，具体取决于工作区的区域和群集类型：
数据复原 通过跨多个可用性区域复制日志数据，为日志数据提供区域冗余。
支持可用性区域的所有区域都提供数据复原能力。 支持可用性区域的大多数区域都需要在 专用群集中部署工作区。 某些地区确实对共享群集的默认工作区配置提供支持。 移动到支持可用性区域的区域中的专用群集可保护移动后引入的数据，而不是历史数据。
服务弹性 提供区域冗余，以便在可用性区发生中断期间维持引入和查询的连续性。
只有某些区域提供服务复原能力。
如果某个事件影响一个可用区，Azure 会自动将故障转移到该区域中的其他可用区。 你无需执行任何操作，因为区域之间可无缝切换。
要求
注意事项
事件中心引入： 在某些区域中，事件中心引入到工作区在区域故障时不具备弹性。 有关这些区域的列表，请参阅 受支持区域列表中的脚注。 评估关键数据的备用引入路径。
移动到专用群集： 专用群集仅保护新数据。 将工作区移动到专用群集时，以前引入的数据将保留在共享群集中。 在正常操作下，一切可用，但在区域中断期间，只能访问专用群集中的新数据。
Cost
区域冗余不会影响定价。 共享群集上的工作区按标准工作区价格收费，专用群集上的工作区必须满足群集的承诺层。 启用区域冗余时，两种定价模型都不会更改。 有关定价的详细信息，请参阅 Azure Monitor 定价。
配置可用性区域支持
对于使用共享群集的工作区，在支持Azure Monitor日志可用性区域的区域中创建工作区，则会自动启用区域冗余。
如果区域需要专用群集来支持区域，请部署专用群集，然后将 工作区链接到专用群集。
容量计划和管理
在区域故障期间，由于数据引入和查询重试，您的工作区可能会经历更大的负载。 如果解决方案对日志引入或查询延迟很敏感，即使在发生区域故障期间和之后，请考虑过度预配你在工作区上配置的任何每日上限的容量。 对于专用群集，请选择具有临时引入峰值空间的承诺层。 有关详细信息，请参阅 通过过度预配管理容量。
所有区域正常时的行为
本部分介绍当Log Analytics工作区是区域冗余的，并且所有区域都正常运行时会发生什么情况。
跨区域操作： 对于具有服务复原能力的群集，引入和查询可以使用任何区域中的基础结构。 该服务会自动跨区域分配工作，针对位置和负载进行优化。
跨区域数据复制： 对于具有数据恢复能力的群集，Azure Monitor服务会在确认之前把所有写入操作提交到不同区域内的多个副本。
区域故障期间的行为
本部分介绍当 Log Analytics 工作区具备区域冗余特性时，以及某个区域发生故障时的预期情况。
检测和响应： 平台会检测区域故障并自动响应。 对于具有服务复原能力的群集，平台会将引入和查询计算重新分配到生存区域。 对于具有数据复原能力的群集，平台会切换到在正常区域中使用副本。 无需启动区域故障转移。
Notification： Azure不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。
还可以监视工作区的运行状况指标，并查找持续的数据摄取延迟或较高的查询失败率。 可以针对这些指标配置警报。
活动请求： 在区域中断期间，任何活动请求都可能会失败。
任何活动查询可能会终止。 客户端可以重试查询。
对于没有服务复原能力的群集，Azure Monitor服务可能会停止处理尚未提交的数据。 当区域正常时，代理或客户端应用程序可以重试。
预期数据丢失： 对于具有数据复原能力的群集，已完全提交的数据预期不会丢失。 代理或客户端需要重试未确认的批次。
预期的停机时间： 对于具有服务复原能力的群集，预计不会停机。 由于服务在跨区域重新平衡基础结构时，可能会发生临时延迟增加或限流。
Rerouting： 对于具有服务复原能力的群集，Azure Monitor日志服务中的内部负载均衡器会将流量重定向到正常的区域节点。 不需要任何终结点更改。
区域恢复
当可用性区域恢复时，Azure Monitor日志会自动将区域重新集成到活动服务拓扑中。 恢复区开始处理排队等待引入的数据，以及与其他区域一起进行查询。 在服务中断期间复制到幸存区域的数据保持不变，所有区域中的正常同步复制都会恢复。 无需采取任何措施进行区域恢复和重新集成。
测试区域故障
Azure管理区域故障的流量路由、故障转移和区域恢复，因此无需验证可用性区域故障进程或提供进一步的输入。
对区域范围的故障的复原能力
Azure Monitor 日志通过工作区日志复制功能提供多区域支持。
工作区复制
工作区复制在受支持的次要区域中创建辅助工作区，然后异步复制新日志以及架构和配置更改。 在配置复制之前预先存在的数据不会回填。
不会将辅助工作区视为可以管理的单独工作区。 访问仍然通过相同的工作区资源终结点进行。
如果主要区域失败，则必须使用 API 触发切换。 切换会将数据引入和查询重新路由到辅助工作区。 没有自动故障转移。 切换是手动决策。 必须触发用户主动发起的切回操作，以恢复主系统。
本部分总结了工作区复制的重要方面。 查看完整的文档以了解其工作原理。
注释
Azure Monitor 日志工作区复制使用术语 switchover，因为该术语最准确地描述了手动切换到辅助工作区的过程。 还可能会出现用于描述常规过程的术语“故障转移”。
要求
区域支持： 工作区复制需要选择同一 区域组中的次要区域。 某些区域组合不能直接指向对方。
专用群集： 如果工作区链接到专用群集，请先在群集上启用复制。
注意事项
日志搜索警报规则：日志搜索警报规则 在区域之间切换时继续工作，除非活动区域中的警报服务无法正常工作，否则警报规则不可用。 例如，如果创建警报规则的区域完全关闭，则可能会发生这种情况。 跨区域复制警报规则不会作为工作区复制的一部分自动完成，但可由用户完成（例如，从主要区域导出并导入到次要区域）。
手动切换和切换： 你负责决定何时切换和切换回，以及触发切换和切换回操作。
若要为区域故障做好准备，应：
- 为活动区域建立监控（复制状态、数据引入延迟、工作区状态指标）。 在切换之前审核非活动工作区区域。
- 考虑是否创建 Runbook 来定义切换条件，这些条件可能构成灾难恢复规划的一部分。 例如，可以监视区域范围的引入延迟、SLO 泄露、持续查询失败率或Azure 服务运行状况公告。 定期测试您的运行手册。
- 记录切换和切换回条件。
辅助表： 不会复制辅助表。 最好不要在包含辅助表的工作区上启用复制。
Microsoft Sentinel： Microsoft Sentinel 监视列表和威胁情报条目仅在刷新的时候复制，因此在初始激活后最多可能需要 12 天才能实现完全同步。
清除操作： 清除操作从主要和辅助数据库中删除记录。 如果任一工作区不可用，清除将失败。 这意味着你需要相应地规划合规性时间线。
有关更多注意事项，请参阅 部署注意事项。
Cost
启用工作区复制时，需要为所有引入到工作区的数据的复制付费。 复制成本受 DCR 参与复制的影响。 有关定价的详细信息，请参阅 Azure Monitor 定价。
配置多区域支持
启用工作区复制： 启用工作区复制所需的常规步骤包括：
-
小窍门
即使预配状态 为“成功”，表架构仍可能正在复制。 若要验证表架构是否完全复制， 请审核辅助工作区。
在启用复制以在切换期间复制这些流后，将数据收集规则（DCR）与工作区数据收集终结点（DCE）相关联。
禁用工作区复制： 有关禁用工作区复制的详细步骤，请参阅 “启用和禁用工作区复制”。
禁用复制会停止复制新日志，但在功能完全禁用之前不会删除已复制的副本。 若要监视禁用操作的进度，请参阅 “检查工作区预配状态”。
容量计划和管理
在地区故障或其他切换或切换回事件期间，由于数据引入和查询重试，您的工作区可能会面临更大的负载。 如果解决方案对日志引入或查询延迟很敏感，即使在区域故障期间和之后也是如此，请考虑过度预配你在工作区上配置的任何每日上限的容量。 对于专用群集，请选择具有临时引入峰值空间的承诺层。 有关详细信息，请参阅 通过过度预配管理容量。
当所有区域都正常时的行为
本节介绍配置 Log Analytics 工作区以进行工作区复制时的预期情况，并且所有区域均正常运行。
跨区域操作： 所有引入和查询都以主要区域的工作区为目标，同时运行正常。 次要区域的工作区保留数据、架构和配置的被动副本，直到切换。
跨区域数据复制： 新的日志、架构和配置更新以批处理方式异步复制到辅助数据库。 由于这是异步的，因此此复制过程不会影响引入延迟。
工作区复制适用于工作区级别，因此无法选择要复制的单个表。 但是，通过仅将携带关键数据流的 DCR 与工作区的数据收集终结点相关联来控制复制。 未与工作区 DCE 关联的 DCR 不会复制其数据。 有关详细信息，请参阅 “关联数据收集规则”。
区域故障期间的行为
本部分介绍在为Log Analytics工作区配置工作区复制功能时预期会发生的情况，并且当其中一个区域发生中断时会遇到的情况。
检测和响应： 你负责决定何时将辅助工作区切换为新的主工作区。 Azure不会做出此决定，也不会为你启动该过程，即使发生区域中断也是如此。 切换和切回是手动操作。
Notifications： Azure不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报通知问题。
为了帮助验证辅助工作区的新鲜度，可以监视复制状态，并审核辅助工作区。
活动请求： 对失败区域的任何活动引入都可能会失败，并且失败区域中正在进行的任何查询也可能失败。
切换过程更改工作区的 DNS 条目后，辅助工作区可用于引入和查询。 Azure的代理自动重试失败的日志引入尝试。 使用日志引入 API 的应用程序还应重试。
预期数据丢失： 尚未复制的任何日志或其他更改在次要区域中不可用。
切换到次要区域后，如果主要区域无法处理传入日志数据，Azure Monitor将次要区域中的数据缓冲长达 11 天。 在前四天内，Azure Monitor自动重新尝试以定期复制数据。
数据丢失总量有时称为恢复点目标（RPO）。
预期的停机时间： 切换过程涉及引入正在激活的辅助工作区，以及对工作区的 DNS 记录的更新。
尽管 DNS 记录更改很快发生，但 DNS 传播可能需要更长的时间。 如果代理或其他客户端不遵循 DNS 生存时间 (TTL)，可能会继续尝试对主工作区进行数据摄取。 确保客户端的 DNS 条目缓存时间不超过其 TTL。
切换完成后，将针对辅助数据库恢复查询。
辅助工作区可用前的总时间有时称为恢复时间目标（RTO）。
重新分配： 切换过程会更新导入终结点的 DNS 记录，使其指向次要区域。 平台在内部将查询路由到活动区域。
当工作区处于切换状态时，日志复制会使用异步复制回到主要区域。
区域恢复
切换是手动的，你负责决定何时切换回来。 主数据库稳定且同步后，可以触发恢复切换。 验证在次级服务器中没有日志积压，并且复制已成功从还原的主服务器继续。
针对区域故障进行测试
您可以随时触发切换和切换回，包括进行测试或灾难恢复演练。
如果执行演练，建议遵循以下最佳做法：
- 使用非生产环境，或者如果在生产环境中进行测试，请在低风险时间范围内运行该过程。
- 如果可能，请根据自己的策略模拟触发区域故障转移条件的条件。 使用此方法可以测试您的检测机制和自动化系统，以及转换和恢复过程。
- 测量 RTO（切换完成）和 RPO（最大未复制间隔）。 使用导出的数据集验证主工作区和辅助工作区之间示例记录的一致性。
用于复原的自定义多区域解决方案
如果工作区复制不适用于你的区域，或者必须使用工作区复制不支持的表类型，请考虑以下用于多区域复原的替代方法：
双重写入： 配置源（例如诊断设置、代理和基于 DCR 的引入），以将日志发送到不同区域中的两个独立的工作区。
此方法在两个区域中提供近实时分析。 但是，引入成本大约是两倍，并引入了工作区之间的配置偏差风险。
导出和再水合：如果您的区域与其他 Azure 区域配对，可以使用数据导出连续将日志导出到 Azure Blob 存储。 将存储帐户配置为使用异地冗余存储（GRS）类型之一。 Azure 存储自动和异步地将导出的日志复制到配对区域。
在灾难期间，部署新工作区并有选择地引入最近的关键数据。 还可以使用 Azure 数据资源管理器 直接从Blob 存储手动查询长期历史记录。 有关详细信息，请参阅 查询导出的数据。
备份和还原
Azure Monitor 日志并不提供传统意义上的时间点备份或恢复功能。 相反，持久性和恢复依赖于区域内部复制（包括区域冗余）、可选的工作区复制和数据导出来维护外部副本。 若要在发生故障后快速分析恢复，请依赖于平台复制而不是还原操作。
可以启用 data export，该导出会自动将日志的副本导出到 Azure 存储。 如果Azure区域已配对，则可以考虑启用异地冗余存储（GRS），将日志数据复制到配对区域。
意外删除的复原能力
若要满足严格的合规性要求和篡改保护，请考虑使用 不可变策略 来防止从存储帐户中删除日志数据。
服务维护期间的系统弹性能力
Microsoft定期应用服务更新并执行其他维护。 Azure平台会自动处理这些活动，确保维护是无缝且透明的。 除非通过Azure 服务运行状况 计划内维护通知，否则在维护事件期间不会造成停机。
为了最大程度地减少维护的影响，Azure Monitor跨工作区副本和可用性区域执行滚动维护。
如果解决方案对引入和查询延迟敏感，请在计划性维护事件期间和之后监视引入延迟和工作区运行状况指标。
某些长时间运行的配置更改可能占用大量资源，例如启用复制、链接群集和添加大型架构。 如果需要进行这些更改，建议避免在计划平台维护时安排这些更改。 使用Azure 服务运行状况计划内维护来了解何时计划维护。
服务级别协议
Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。
Azure Monitor 日志在在线服务中具有独特之处，因为它是建议的平台，用于提供提交 Azure 支持请求所需的基本数据和见解，以解决与 SLA 相关的问题。
有两个 SLA 涵盖该服务：
Log Analytics（查询可用性 SLA）定义从Log Analytics工作区查询数据的可用性预期。
Azure Monitor SLA定义警报规则和操作组的可用性预期，包括分析遥测信号和通知传递。