你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Monitor 日志的最佳做法
本文提供了 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 工作区中合并操作数据和安全数据。
- 为组织中不同角色所需的工作区中不同类型的数据配置访问权限。
- 考虑使用 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 天）。 请考虑使数据随时可用于日志查询的特定要求。 你可以通过配置长期保留来显著降低成本，它允许将数据保留长达 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 中优化日志查询。 |