你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Monitor 日志的最佳做法
本文提供了 Azure Monitor 日志的体系结构最佳做法。 本指南基于 Azure 架构良好的框架中描述的卓越体系结构的五大支柱。
可靠性
可靠性是指系统能够从故障中恢复并继续正常运行。 我们的目标不是试图在云中防止各种故障，而是最大程度地减轻单个组件故障造成的影响。 使用以下信息将 Log Analytics 工作区的故障降到最低，并保护它们收集的数据。
Log Analytics 工作区提供高度可靠性。 Azure Monitor 代理和数据引入管道的内置保护机构提供的数据缓冲等功能通常可缓解由于暂时失去工作区访问权限而导致的数据丢失。
本节中所述的复原功能可以提供额外的保护，防止数据丢失，保证业务连续性。 有些是区域内解决方案，另一些解决方案提供跨区域冗余；部分解决方案会自动应用，而其他的则需要手动触发。 下表总结并比较了这些功能。
某些可用性功能要求有一个专用群集，目前所有链接到此群集的工作区（聚合）每天至少需要承诺使用 100 GB。
设计清单
- 如果为专用群集收集了足够的数据，请在可用性区域中创建专用群集。
- 如果要求工作区在发生区域故障时可用，或者没有为专用群集收集足够的数据，请将数据收集配置为将关键数据发送到不同区域中的多个工作区。
- 如果需要在数据中心或区域发生故障时保护数据，请配置从工作区导出的数据，将数据保存在备用位置。
- 对于需要高可用性的任务关键型工作负载，请考虑实现联合工作区模型。
- 监视 Log Analytics 工作区的运行状况。
配置建议
| 建议 | 好处 |
|---|---|
| 如果收集了足够的数据，请在支持可用性区域的区域中创建专用群集。 | 如果数据中心发生故障，链接到位于支持可用性区域的区域中的专用群集的工作区仍然可用。 专用群集需要承诺同一区域中的所有工作区每天至少有 100 GB。 如果不收集这么多数据，则需要使用它提供的可靠性功能以权衡此承诺的成本。 |
| 如果要求工作区中的数据在发生区域故障时可用，请将关键数据发送到不同区域中的多个工作区。 | 发送数据到不同区域的多个工作区。 例如，配置多个 DCR 以从虚拟机上运行的 Azure Monitor 代理发送数据到多个工作区，并为多个工作区设置多个诊断设置以从 Azure 资源收集资源日志。 即使发生故障时备用工作区中的数据仍可用，但依赖于数据的资源（如警报和工作簿）不会使用此工作区。 考虑使用 Azure DevOps 中的备用工作区的配置来存储 ARM 模板，或将其用作可在故障时快速启用的禁用策略。 权衡：此配置会导致重复的引入和数据保留费用，因此仅将其用于关键数据。 |
| 对于需要高可用性的任务关键型工作负载，请考虑实现使用多个工作区的联合工作区模型，以在发生区域性故障时提供高可用性。 | 任务关键型为在 Azure 上生成高度可靠的应用程序提供了规范性最佳做法指南。 设计方法包括具有多个 Log Analytics 工作区的联合工作区模型，用于在发生多个故障（包括 Azure 区域故障）时提供高可用性。 此策略可消除跨区域的出口成本，并在发生区域故障时仍可正常运行，但它需要额外的复杂性，你必须使用Azure 上任务关键型工作负载的运行状况建模和可观测性中所述的配置和流程进行管理。 |
| 如果需要在数据中心或区域发生故障时保护数据，请配置从工作区导出的数据，将数据保存在备用位置。 | 使用 Azure Monitor 的数据导出功能，可将发送到特定表的数据持续导出到 Azure 存储，以便长时间保留数据。 使用 Azure 存储冗余选项（包括 GRS 和 GZRS）将此数据复制到其他区域。 如果需要导出的表不受数据导出支持，可以使用其他导出数据的方法（包括逻辑应用）来保护数据。 这主要是满足数据保留合规性的解决方案，因为数据可能难以分析和还原到工作区。 此选项类似于将数据多播到不同工作区的上一个选项，但成本较低，因为额外数据将写入存储。 数据导出容易受到区域事件的影响，因为它依赖于区域中 Azure Monitor 引入管道的稳定性。 它不会针对影响区域引入管道的事件提供复原能力。 |
| 监视 Log Analytics 工作区的运行状况。 | 使用Log Analytics 工作区见解跟踪失败的查询，并创建运行状况警报，从而在工作区因数据中心或区域性故障变得不可用时主动通知你。 |
比较复原特性和功能
| 功能 | 服务复原能力 | 数据备份 | 高可用性 | 保护范围 | 安装 | 成本 |
|---|---|---|---|---|---|---|
| 可用性区域 | ✅ 在支持的区域 |
✅ | ✅ | 区域内 | 在受支持区域的专用群集上自动启用。 | 免费 |
| 连续数据导出 | ✅ | 区域故障保护1 | 按表启用。 | 数据导出 + 存储 Blob 或事件中心的成本 | ||
| 双引入 | ✅ | ✅ | ✅ | 区域故障保护 | 按受监视资源启用。 | 保留成本高达两倍（具体取决于双重引入的数据量） + 流出费用。 |
1 数据导出在将日志导出到其他区域时提供跨区域保护。 发生事件时，会备份之前导出的数据，且数据随时可；但是，根据事件的性质，后续导出可能会失败。
安全性
安全是体系结构的首要考虑因素之一。 Azure Monitor 提供了采用最低特权原则和深度防御原则的功能。 使用以下信息最大程度地提高 Log Analytics 工作区的安全性，并确保只有授权用户可以访问收集的数据。
设计清单
- 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。
- 为组织中不同角色所需的工作区中不同类型的数据配置访问权限。
- 考虑使用 Azure 专用链接删除从公用网络访问工作区的权限。
- 如果需要使用自己的加密密钥来保护工作区中的数据和保存的查询，请使用客户管理的密钥。
- 导出审核数据以长期保留或确保不可变性。
- 配置日志查询审核以跟踪哪些用户正在运行查询。
- 确定筛选或模糊处理工作区中的敏感数据的策略。
- 清除意外收集的敏感数据。
- 启用 Microsoft Azure 客户密码箱以批准或拒绝 Microsoft 数据访问请求。
配置建议
| 建议 | 好处 |
|---|---|
| 确定是否在同一 Log Analytics 工作区中合并操作数据和安全数据。 | 是否合并此数据取决于具体的安全要求。 尽管安全团队可能需要专用工作区，但将它们组合在单个工作区中可让你更好地了解所有数据。 请参阅设计 Log Analytics 工作区策略，详细了解如何针对环境做出此决策，使之与其他支柱中的准则保持平衡。 权衡：在工作区中启用 Sentinel 会产生潜在的成本影响。 请参阅设计 Log Analytics 工作区体系结构的详细信息。 |
| 为组织中不同角色所需的工作区中不同类型的数据配置访问权限。 | 将工作区的访问控制模式设置为“使用资源或工作区权限”，以允许资源所有者使用资源上下文访问其数据，而无需授予对工作区的显式访问权限。 这简化了工作区配置，并有助于确保用户无法访问他们不应访问的数据。 分配适当的内置角色，以根据管理员的职责范围，在订阅、资源组或工作区级别向管理员授予工作区权限。 为需要跨多个资源访问一组表的用户利用表级别 RBAC。 无论其资源权限如何，具有表权限的用户都可以访问表中的所有数据。 有关授予对工作区中数据的访问权限的不同选项的详细信息，请参阅管理对 Log Analytics 工作区的访问权限。 |
| 考虑使用 Azure 专用链接删除从公用网络访问工作区的权限。 | 与公共终结点的连接通过端到端加密进行保护。 如果需要专用终结点，可以使用 Azure 专用链接允许资源通过授权的专用网络连接到 Log Analytics 工作区。 专用链接还可用于通过 ExpressRoute 或 VPN 强制引入工作区数据。 请参阅设计 Azure 专用链接设置，确定适合你的环境的最佳网络和 DNS 拓扑。 |
| 如果需要使用自己的加密密钥来保护工作区中的数据和保存的查询，请使用客户管理的密钥。 | Azure Monitor 确保使用 Microsoft 管理的密钥 (MMK) 静态加密所有数据和保存的查询。 如果需要使用自己的加密密钥，并为专用群集收集足够的数据，请使用客户管理的密钥以提高灵活性和密钥生命周期控制。 如果使用 Microsoft Sentinel，请确保熟悉设置 Microsoft Sentinel 客户管理的密钥中的注意事项。 |
| 导出审核数据以长期保留或确保不可变性。 | 你可能在工作区中收集了审核数据，这些数据受制于要求其长期保留的法规。 无法更改 Log Analytics 工作区中的数据，但可以清除这些数据。 使用数据导出将数据发送到具有不可变性策略的 Azure 存储帐户，以防止数据篡改。 并非每种类型的日志在合规性、审核或安全性方面都具有相同的相关性，因此请确定应导出的特定数据类型。 |
| 配置日志查询审核以跟踪哪些用户正在运行查询。 | 日志查询审核会记录工作区中运行的每个查询的详细信息。 像安全数据一样对待此数据，并确保 LAQueryLogs 的安全。 配置要发送到本地工作区的每个工作区的审核日志，如果要分离操作和安全数据，则合并到专用安全工作区中。 使用 Log Analytics 工作区见解定期查看此数据，并考虑创建日志搜索警报规则，以便在未经授权的用户尝试运行查询时主动通知你。 |
| 确定筛选或模糊处理工作区中的敏感数据的策略。 | 你可能正在收集包含敏感信息的数据。 使用特定数据源的配置以筛选不应收集的记录。 如果只应删除或模糊处理数据中的特定列，请使用转换。 如果标准要求未修改的原始数据，则可以在 KQL 查询中使用“h”文本来模糊处理工作簿中显示的查询结果。 |
| 清除意外收集的敏感数据。 | 定期检查工作区中可能意外收集的专用数据，并使用数据清除将其删除。 |
| 启用 Microsoft Azure 客户密码箱以批准或拒绝 Microsoft 数据访问请求。 | Microsoft Azure 客户密码箱为你提供了一个界面来查看和批准/拒绝客户数据访问请求。 它用于 Microsoft 工程师需要访问客户数据的情况，无论是响应客户发起的支持票证还是 Microsoft 发现的问题。 若要启用客户密码箱，需要具有一个专用群集。 |
成本优化
成本优化是指可以减少不必要的费用以及提高运营效率的方法。 通过了解不同的配置选项和减少数据收集量的可能设置，可以显著降低 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 天）。 请考虑使数据随时可用于日志查询的特定要求。 可以通过配置存档日志来显著降低成本，它允许将数据保留长达 7 年，并且仍可偶尔访问这些数据，方法是使用搜索作业或将一组数据还原到工作区。 |
| 将用于调试、故障排除和审核的表配置为基本日志。 | 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 中优化日志查询。 |