你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文提供了 Azure Monitor 日志的体系结构最佳做法。 本指南基于 Azure 架构良好的框架中描述的卓越体系结构的五大支柱。
可靠性
可靠性是指系统能够从故障中恢复并继续正常运行。 目标是将单个故障组件的影响降至最低。 使用以下信息将 Log Analytics 工作区的故障降到最低，并保护它们收集的数据。
Log Analytics 工作区提供高度可靠性。 将数据发送到 Log Analytics 工作区的引入管道将会在从管道中移除记录之前验证 Log Analytics 工作区是否已成功处理每个日志记录。 如果引入管道不可用，则发送数据的代理会对数据进行缓冲，并在接下来的数小时内重试发送日志。
可增强复原能力的 Azure Monitor Logs 功能
Azure Monitor Logs 提供多种功能，可增强工作区对各类型问题的复原能力。 你可以根据需求单独或组合使用这些功能。
此视频概述了 Log Analytics 工作区可用的可靠性和复原选项：
使用可用区实现区域内保护
每个支持可用区的 Azure 区域都有一组配备了独立电源、冷却和网络基础结构的数据中心。
Azure Monitor Logs 可用区具有冗余性，这意味着 Microsoft 会在支持区域中的不同可用区之间分散服务请求和复制数据。 如果事件影响一个可用区，Microsoft 会自动改用区域中的另一个可用区。 你无需执行任何操作，因为区域之间可无缝切换。
在大多数区域中，Azure Monitor Logs 可用区都支持数据复原，这意味着存储的数据可以防范与可用区故障相关的数据丢失，但服务操作仍可能受到区域性事件的影响。 如果服务无法运行查询，则在解决问题之前无法查看日志。
支持数据复原的可用区子集还支持服务复原，这意味着 Azure Monitor Logs 服务操作（例如日志引入、查询和警报）可以在发生可用区故障时继续进行。
可用区可防范与基础结构相关的事件，例如存储故障。 它们不会防范应用程序级问题，例如故障代码部署或证书故障，这会影响整个区域。
使用连续导出功能备份特定表中的数据
你可以将发送到 Log Analytics 工作区的特定表中的数据连续导出到 Azure 存储帐户。
接收导出数据的存储帐户必须与 Log Analytics 工作区位于同一区域。 为了确保即使在工作区区域出现故障时也能保护并有权访问引入的日志，请使用异地冗余存储帐户，如配置建议中所述。
导出机制不提供对影响引入管道或导出进程本身的事件的保护。
注释
你可以使用 externaldata 运算符从 Azure Monitor Logs 访问存储帐户中的数据。 但是，导出的数据将存储在持续期为 5 分钟的 blob 中，分析跨越多个 blob 的数据可能会比较繁琐。 因此，将数据导出到存储帐户是一个很好的数据备份机制，但如果需要在 Azure Monitor Logs 中对其进行分析，则将备份的数据存储在存储帐户中并不是一种理想的处理方式。 你可以使用 Azure 数据资源管理器、Azure 数据工厂或任何其他存储访问工具来查询大量 blob 数据。
使用工作区复制实现跨区域数据保护和服务复原能力
工作区复制是最广泛的复原解决方案，因为它将 Log Analytics 工作区和传入日志复制到另一个区域。
工作区复制可同时保护日志和服务操作，并允许在发生基础结构或应用程序相关的区域级事件时继续监视系统。
与由 Microsoft 进行端到端管理的可用区相比，你需要监视主工作区的运行状况，并决定何时切换到次要区域中的工作区以及何时切换回来。
设计清单
- 若要确保对区域级事件的服务和数据复原能力，请启用工作区复制。
- 若要确保可防范数据中心故障的区域内保护，请在支持可用区的区域内创建工作区。
- 对于针对特定表中数据的跨区域备份，请使用连续导出功能将数据发送到异地复制的存储帐户。
- 监视 Log Analytics 工作区的运行状况。
配置建议
| 建议 | 益处 |
|---|---|
| 若要确保达到最大的复原能力，请启用工作区复制。 | 工作区数据和服务操作的跨区域复原能力。 工作区复制 通过在另一个区域中创建工作区的辅助实例并将日志引入这两个工作区来确保高可用性。 如果需要，请切换到次要工作区，直到影响主工作区的问题得到解决。 你可以继续在次要工作区中收集日志、查询数据，以及使用警报、仪表板和 Sentinel。 你还可以访问在区域切换之前引入的日志。 这是一项付费功能，因此请考虑是复制所有传入日志还是仅复制某些数据流。 |
| 如果可能，请在支持 Azure Monitor 服务复原的区域中创建工作区。 | 发生数据中心问题时，工作区数据和服务操作的区域内复原能力。 支持服务复原的可用区也支持数据复原。 这意味着，即使整个数据中心不可用，可用区之间的冗余也允许 Azure Monitor 服务操作（如引入和查询）继续进行，且引入的日志保持可用。 可用区提供区域内保护，但无法防范影响整个区域的问题。 有关哪些区域支持数据复原的信息，请参阅使用可用区增强 Azure Monitor Logs 中的数据和服务复原能力。 |
| 在支持数据复原的区域中创建工作区。 | 在数据中心发生问题时，提供区域内保护，防止工作区日志丢失。 在支持数据复原的区域中创建工作区意味着，即使整个数据中心不可用，引入的日志也是安全的。 如果服务无法运行查询，则在解决问题之前无法查看日志。 有关哪些区域支持数据复原的信息，请参阅使用可用区增强 Azure Monitor Logs 中的数据和服务复原能力。 |
| 配置数据导出功能，将特定表的数据导出到在多个区域进行复制的存储帐户中。 | 在其他区域中维护日志数据的备份副本。 使用 Azure Monitor 的数据导出功能，可将发送到特定表的数据持续导出到 Azure 存储，以便长时间保留数据。 请使用异地冗余存储 (GRS) 或异地可用区冗余存储 (GZRS) 帐户来确保数据即使在整个区域都不可用时也是安全的。 若要使数据可从其他区域读取，请为存储帐户配置对次要区域的读取访问权限。 有关详细信息，请参阅次要区域中的 Azure 存储冗余和 Azure 存储对次要区域中数据的读取访问权限。 对于不支持连续数据导出的表，可以使用其他导出数据的方法（包括逻辑应用）来保护数据。 这主要是满足数据保留合规性的解决方案，因为数据可能难以分析和还原到工作区。 数据导出容易受到区域事件的影响，因为它依赖于区域中 Azure Monitor 引入管道的稳定性。 它不会针对影响区域引入管道的事件提供复原能力。 |
| 监视 Log Analytics 工作区的运行状况。 | 使用Log Analytics 工作区见解跟踪失败的查询，并创建运行状况警报，从而在工作区因数据中心或区域性故障变得不可用时主动通知你。 |
比较 Azure Monitor 日志的复原功能
| 功能 / 特点 | 服务复原能力 | 数据备份 | 高可用性 | 保护范围 | 设置 | 成本 |
|---|---|---|---|---|---|---|
| 工作区复制 | ✅ | ✅ | ✅ | 针对区域级事件的跨区域保护 | 启用对工作区及其相关数据收集规则的复制功能。 根据需要在区域之间切换。 | 基于已复制的 GB 数和区域。 |
| 可用性区域 | ✅ 在支持的区域中 |
✅ | ✅ | 针对数据中心问题的区域内保护 | 在受支持的区域中自动启用。 | 无成本 |
| 连续数据导出 | ✅ | 防范因区域性故障导致的数据丢失1 | 逐个表启用。 | 数据导出 + 存储 blob 或事件中心的成本 |
1 如果将日志导出到异地复制的存储帐户，数据导出可提供跨区域保护。 发生事件时，会备份之前导出的数据，且数据随时可；但是，根据事件的性质，后续导出可能会失败。
安全
安全是体系结构的首要考虑因素之一。 Azure Monitor 提供了采用最低特权原则和深度防御原则的功能。 使用以下信息最大程度地提高 Log Analytics 工作区的安全性，并确保只有授权用户可以访问收集的数据。
根据需要授予对工作区中的数据的访问权限
- 将工作区访问控制模式设置为 “使用资源或工作区权限 ”，以允许资源所有者使用 资源上下文 访问其数据，而无需授予对工作区的显式访问权限。 这简化了工作区配置，并帮助确保用户只能访问所需的数据。
说明： 管理对 Log Analytics 工作区的访问权限 - 分配适当的内置角色，根据管理员的职责范围向订阅、资源组或工作区级别的管理员授予工作区权限。
说明： 管理对 Log Analytics 工作区的访问权限 - 对需要跨多个资源访问一组表的用户应用表级 RBAC。 无论其资源权限如何，具有表权限的用户都可以访问表中的所有数据。
说明： 管理对 Log Analytics 工作区的访问权限
使用传输层安全性 （TLS） 1.2 或更高版本将数据发送到工作区
如果使用代理、连接器或日志引入 API 将数据发送到工作区，请使用传输层安全性 （TLS） 1.2 或更高版本来确保传输中的数据的安全性。 旧版 TLS/安全套接字层（SSL）已发现易受攻击，尽管它们目前仍可允许向后兼容性，但 不建议这样做，并且行业正在迅速放弃对这些旧协议的支持。
PCI 安全标准委员会规定 2018 年 6 月 30 日是停用旧版 TLS/SSL 并升级到更安全协议的截止时间。 Azure 删除旧版支持后，如果代理无法通过 TLS 1.3 进行通信，将无法将数据发送到 Azure Monitor 日志。
建议不要将代理显式设置为仅使用 TLS 1.3，除非必要。 最好允许代理自动检测、协商和利用未来的安全标准。 否则，您可能会错过较新标准所带来的额外安全性，并在 TLS 1.3 被弃用以采用这些较新标准时可能会遇到问题。
重要
2025 年 7 月 1 日，与 Azure 范围的旧版 TLS 停用一致，将为 Azure Monitor 日志停用 TLS 1.0/1.1 协议版本。 为了提供一流的加密，Azure Monitor 日志使用传输层安全性 （TLS） 1.2 和 1.3 作为所选加密机制。
有关旧 TLS 问题的任何常规问题，请参阅解决 TLS 问题和Azure 资源管理器 TLS 支持。
设置日志查询审核
- 配置日志查询审核，以记录在工作区中运行的每个查询的详细信息。
说明： Azure Monitor 日志中的审核查询 - 将日志查询审核数据视为安全数据，并适当地安全访问 LAQueryLogs 表。
说明： 根据需要配置对工作区中数据的访问。 - 如果将操作数据和安全数据分离，请将每个工作区的审核日志发送到本地工作区，或汇总到专用安全工作区中。
说明： 根据需要配置对工作区中数据的访问。 - 使用 Log Analytics 工作区洞察功能定期审查日志查询审核数据。
说明： Log Analytics 工作区分析见解。 - 创建日志搜索警报规则，以便在未经授权的用户尝试运行查询时通知你。
说明： 日志搜索警报规则。
确保审核数据的不可变性
Azure Monitor 是一个仅可追加的数据平台，但它包含为符合性目的而删除数据的规定。 保护审核数据：
在你的 Log Analytics 工作区上设置锁定，以阻止所有可能删除数据的活动，包括清除、表删除、表级或工作区级的数据保留更改。 但是，请记住，可以删除此锁。
说明： 锁定资源以保护基础结构如果需要完全防篡改的解决方案，建议将数据导出到 不可变存储解决方案：
- 确定应导出的特定数据类型。 并非所有日志类型都具有与合规性、审核或安全性相同的相关性。
- 使用 数据导出 将数据发送到 Azure 存储帐户。
说明： Azure Monitor 中的 Log Analytics 工作区数据导出 - 设置不可变策略以防止数据篡改。
说明： 为 Blob 版本配置不可变性策略
筛选或模糊处理工作区中的敏感数据
如果日志数据包含 敏感信息：
- 使用特定数据源的配置以筛选不应收集的记录。
- 如果只应删除或模糊处理数据中的特定列，请使用转换。
说明： Azure Monitor 中的转换 - 如果你有要求未修改原始数据的标准，请使用 KQL 查询中的“h”文本模糊化工作簿中显示的查询结果。
说明：经过模糊处理的字符串文本
清除意外收集的敏感数据
- 定期检查工作区中可能意外收集的专用数据。
- 使用 数据清除 删除不需要的数据。 请注意，目前无法清除具有 辅助计划的 表中的数据。
说明： 在 Azure Monitor 日志和 Application Insights 中管理个人数据
将工作区链接到专用群集以提高安全性
Azure Monitor 使用 Microsoft 管理的密钥 (MMK) 加密所有静态数据和保存的查询。 如果为 专用群集收集足够的数据，请将工作区链接到专用群集，以获取增强的安全功能，包括：
- 客户管理的密钥 可提高灵活性和密钥生命周期控制。 如果使用 Microsoft Sentinel，请确保熟悉设置 Microsoft Sentinel 客户管理的密钥中的注意事项。
- Microsoft Azure 的客户密码箱 ，用于查看和批准或拒绝客户数据访问请求。 在 Microsoft 工程师需要访问客户数据时（无论是为了响应客户发起的支持工单，还是为了处理由 Microsoft 识别的问题），会用到客户密码箱。 密码箱当前不能应用于具有辅助计划的表。
说明： 在 Azure Monitor 日志中创建和管理专用群集
使用 Azure 专用链接阻止来自公用网络的工作区访问
Microsoft使用端到端加密保护与公共终结点的连接。 如果需要专用终结点，请使用 Azure 专用链接 允许资源通过授权的专用网络连接到 Log Analytics 工作区。 还可以使用专用链接强制通过 ExpressRoute 或 VPN 引入工作区数据。
说明： 设计 Azure 专用链接设置
成本优化
成本优化是指可以减少不必要的费用以及提高运营效率的方法。 通过了解不同的配置选项和减少数据收集量的可能设置，可以显著降低 Azure Monitor 的成本。 查看 Azure Monitor 成本和使用情况，了解 Azure Monitor 的不同计费方式以及如何查看每月帐单。
注释
有关 Azure Monitor 的所有功能的成本优化建议，请参阅优化 Azure Monitor 中的成本。
设计清单
- 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。
- 为每个 Log Analytics 工作区通常收集的数据量配置定价层。
- 配置数据保留和存档。
- 将用于调试、故障排除和审核的表配置为基本日志。
- 限制从工作区的数据源收集数据。
- 定期分析所收集的数据，以确定趋势和异常。
- 当数据收集量很高时创建警报。
- 考虑使用每日上限作为预防措施，以确保你不超过特定预算。
- 针对 Log Analytics 工作区设置有关 Azure 顾问成本建议的警报。
配置建议
| 建议 | 益处 |
|---|---|
| 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。 | 由于在启用 Sentinel 的情况下，Log Analytics 工作区中的所有数据将按 Microsoft Sentinel 定价计费，因此组合这些数据可能会影响成本。 请参阅设计 Log Analytics 工作区策略，详细了解如何针对环境做出此决策，使之与其他支柱中的准则保持平衡。 |
| 为每个 Log Analytics 工作区通常收集的数据量配置定价层。 | 默认情况下，Log Analytics 工作区将使用即用即付定价，没有最少数据量。 如果收集的数据足够多，则可以使用承诺层级来显著降低成本，借此可以承诺每天收集的最小数据量，以获得更低的费率。 如果跨单个区域中的工作区收集了足够多的数据，则可以将它们链接到专用群集，并使用群集定价来合并所收集的数据量。 请参阅 Azure Monitor 日志成本计算和选项，了解有关承诺层的详细信息以及确定最适合你的使用级别的指导。 请参阅使用情况和预估成本，查看使用情况在不同定价层的预估成本。 |
| 配置交互式和长期数据保留策略。 | 在 Log Analytics 工作区中保留数据超过 31 天的默认期限将收取费用（如果在工作区上启用了 Sentinel，则期限为 90 天；对于 Application Insights 数据，也为 90 天）。 请考虑使数据随时可用于日志查询的特定要求。 你可以通过配置长期保留来显著降低成本，它允许将数据保留长达 12 年，并且仍可偶尔访问这些数据，方法是使用搜索作业或将一组数据还原到工作区。 |
| 将用于调试、故障排除和审核的表配置为基本日志。 | 在 Log Analytics 工作区中配置为基本日志的表以较低的引入成本为代价，功能有所限制，并且会对日志查询收取费用。 但如果不经常查询这些表并且不将它们用于警报，则此查询成本可能会被减少的引入成本所抵消。 |
| 限制从工作区的数据源收集数据。 | Azure Monitor 的主要成本因素是你在 Log Analytics 工作区中收集的数据量，因此应确保收集的数据不超过评估服务和应用程序的运行状况和性能所需的数据。 请参阅设计 Log Analytics 工作区体系结构，详细了解如何针对你的环境做出此决策，使其与其他支柱中的条件进行平衡。 权衡：可能需要在成本和监视要求之间做出权衡。 例如，使用高采样率也许能够更快地检测出性能问题，但若想节省成本，则需要使用较低的采样率。 大多数环境都有多个数据源，它们的数据收集类型各不相同，因此对于每个数据源，需要在特定要求与成本目标之间实现平衡。 有关为不同数据源配置数据收集的建议，请参阅 Azure Monitor 中的成本优化。 |
| 定期分析所收集的数据，以确定趋势和异常。 | 使用 Log Analytics 工作区见解定期查看工作区中收集的数据量。 除了帮助你了解不同源收集的数据量外，它还将识别数据收集中可能导致成本过高的异常和上升趋势。 使用分析 Log Analytics 工作区中的使用情况中的方法进一步分析数据收集，以确定是否可以进行其他配置来进一步降低使用量。 添加一组新的数据源（例如一组新的虚拟机或加入新服务）时，这一点尤其重要。 |
| 当数据收集量很高时创建警报。 | 为了避免出现意外账单，应让系统在遇到过度使用时主动通知你。 通知使你可以在计费期结束之前解决任何潜在的异常情况。 |
| 考虑使用每日上限作为预防措施，以确保你不超过特定预算。 | 达到配置的限制后，每日上限会在一天的剩余时间内禁用 Log Analytics 工作区中的数据收集。 不应将此方法用于降低成本，如何时使用每日上限中所述。 如果设置了每日上限，则除了在达到上限时创建警报外，还请确保创建一个警报规则，以便在达到某个百分比（例如 90%）时发出通知。 这让你有机会在上限关闭数据收集之前调查并解决数据增加的原因。 |
| 针对 Log Analytics 工作区设置有关 Azure 顾问成本建议的警报。 | 当有机会优化成本时，适用于 Log Analytics 工作区的 Azure 顾问建议会主动发出警报。 为以下成本建议创建 Azure 顾问警报：
|
卓越运营
卓越运营是指使服务在生产环境中可靠运行所需的操作流程。 使用以下信息最大程度地减少支持 Log Analytics 工作区的操作要求。
设计清单
- 设计具有最少数量的工作区的工作区体系结构，以满足业务要求。
- 管理多个工作区时，使用基础结构即代码 (IaC)。
- 使用 Log Analytics 工作区见解跟踪 Log Analytics 工作区的运行状况和性能。
- 创建警报规则，以主动接收工作区中操作问题的通知。
- 确保有定义明确的运营流程用于数据隔离。
配置建议
| 建议 | 益处 |
|---|---|
| 设计工作区策略以满足业务要求。 | 请参阅设计 Log Analytics 工作区体系结构，获取有关为 Log Analytics 工作区设计策略的指导，包括创建数量和放置位置。 单个或至少最少数量的工作区将最大程度地提高运营效率，因为它会限制运营和安全数据的分布，提高对潜在问题的可见性，使模式更易于识别，并最大程度地降低维护要求。 你可能对多个工作区（例如多个租户）有要求，或者可能需要多个区域中的工作区以支持可用性要求。 在这些情况下，请确保有适当的流程来管理这种增加的复杂性。 |
| 管理多个工作区时，使用基础结构即代码 (IaC)。 | 使用基础结构即代码 (IaC) 定义ARM、BICEP或Terraform中工作区的详细信息。 这样就可以利用现有的 DevOps 流程以部署新工作区和Azure Policy以强制执行其配置。 |
| 使用 Log Analytics 工作区见解跟踪 Log Analytics 工作区的运行状况和性能。 | Log Analytics 工作区见解提供了工作区使用情况、性能、运行状况、代理、查询和更改日志的统一视图。 定期查看此信息以跟踪每个工作区的运行状况和操作。 |
| 创建警报规则，以主动接收工作区中操作问题的通知。 | 每个工作区都有一个操作表，用于记录影响工作区的重要活动。 基于此表创建警报规则，以在发生操作问题时主动接收通知。 可以使用针对工作区的建议警报，以简化最关键警报规则的创建。 |
| 确保有定义明确的运营流程用于数据隔离。 | 对于工作区中存储的不同类型的数据，可能有不同的要求。 在设计工作区策略以及配置权限和长期保留等设置时，请确保清楚了解数据保留和安全性等要求。 还应该有明确定义的流程，以便不定期清除意外收集到的包含个人信息的数据。 |
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 使用以下信息确保配置 Log Analytics 工作区和日志查询以获得最佳性能。
设计清单
- 配置日志查询审核，并使用 Log Analytics 工作区见解来识别缓慢和低效的查询。
配置建议
| 建议 | 益处 |
|---|---|
| 配置日志查询审核，并使用 Log Analytics 工作区见解来识别缓慢和低效的查询。 | 日志查询审核存储运行每个查询所需的计算时间和返回结果的时间。 Log Analytics 工作区见解使用此数据列出工作区中可能效率低下的查询。 请考虑重写这些查询以提高其性能。 有关优化日志查询的指南，请参阅在 Azure Monitor 中优化日志查询。 |
后续步骤
- 请详细了解 Azure Monitor 的入门指南。