你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Monitor 中的 Log Analytics 工作区是集中式存储库，用于收集、存储和分析来自 Azure 环境中各种源的日志和性能数据。 这些工作区充当用于监视信息的主要数据接收器，并支持高级查询、可视化和警报功能，以帮助深入了解工作负荷的运行状况和性能。
本文假设作为架构师，你了解了工作负荷的综合监视和可观测性的重要性，并已选择 Log Analytics 工作区作为监视策略的一部分。 本文中的指南提供了与 Azure Well-Architected 框架支柱原则相对应的架构建议。
技术范围
此次审查重点分析以下 Azure 资源的相关决策：
- Log Analytics 工作区
可靠性
可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。
可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。
工作负荷设计清单
根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时牢记应用程序的性质及其组件的关键性。 扩展策略以根据需要包含更多方法。
查看 Log Analytics 工作区的服务限制： 服务限制部分介绍了对数据收集、数据保留和其他服务方面的限制。 这些限制有助于设计有效的工作负荷可观测性策略。 请确保查看 Azure Monitor 服务限制 ，因为许多函数（如查询）可与 Log Analytics 工作区协同工作。
规划工作区复原和恢复： Log Analytics 工作区是区域性的，没有对跨区域冗余或复制的内置支持。 可用性区域冗余选项有限。 由于这些限制，应确定工作区的可靠性要求，并制定策略来满足这些目标。
你的要求可能规定工作区必须能够复原到数据中心故障或区域故障。 或者，他们可能会规定，你必须能够将数据恢复到故障转移区域中的新工作区。
每个方案都需要额外的资源和流程才能成功，因此请仔细考虑如何通过成本和复杂性平衡可靠性目标。
选择适当的部署区域以满足可靠性要求： 部署 Log Analytics 工作区和数据收集终结点（DCE）与发出作数据的工作负荷组件并置。 在何处 部署工作负荷 时，应通知你选择在其中部署工作区和 DCE 的相应区域。
可能需要根据工作负荷可靠性、成本和性能要求更集中的其他因素来权衡特定 Log Analytics 功能的区域可用性，例如专用群集。
从关键路径依赖项中排除工作区： Log Analytics 工作区充当可观测性系统的重要组件，但不应将它们包含在 工作负荷的关键路径中。 这些工作区收集和存储对监视和故障排除至关重要的作数据。 但是，工作负荷的核心功能必须独立于工作区可用性。 这种体系结构分离可确保可观测性系统中断不会级联到工作负荷运行时故障中。
确保可观测性系统正常运行： 与工作负荷的任何其他组件一样，请确保监视和日志记录系统正常运行。 若要实现可靠的可观测性，请启用向运营团队发送运行状况数据信号的功能。 设置特定于 Log Analytics 工作区和关联资源的运行状况数据信号。
配置建议
| 建议 | 益处 |
|---|---|
| 若要支持工作区数据的持久性高，请将 Log Analytics 工作区部署到支持数据复原 的区域 。 | 数据复原将日志数据的副本分散到可用性区域，从而防止数据中心中断。 |
| 请考虑将工作区链接到同一区域中的 专用群集 。 | 即使现在没有收集足够的数据来证明专用群集的合理性，这种先发制人的区域选择也有助于支持未来的增长。 |
| 将工作区部署到与工作负荷实例相同的区域中。 使用 Log Analytics 工作区所在的同一区域中的 DCE 。 如果工作负荷部署在主动-主动设计中，请考虑使用分布在部署工作负荷的区域的多个工作区和 DCE。 |
将工作区和 DCE 与工作负荷位于同一区域可降低其他区域中中断影响的风险。 在多个区域中部署工作区会增加环境的复杂性，但为地理分布式工作负荷提供更好的可用性。 |
| 配置日志多播，以在发生区域故障时将 关键数据发送到 不同区域中的多个工作区。 设置 数据收集规则（DCR） 和 诊断设置 ，以将关键日志流复制到备份工作区。 存储 Azure 资源管理器模板（ARM 模板），以便通过备用工作区配置来提醒资源以实现快速故障转移。 |
日志多播可确保持续访问关键作数据，以便在区域性服务中断期间进行故障排除和事件响应。 当主监视基础结构不可用时，此访问权限可保持对工作负荷运行状况的可见性。 权衡：此配置会产生重复的引入和保留费用，因此只将其用于关键数据。 |
| 如果需要在数据中心或区域故障中保护数据，请配置从工作区 导出的数据 以在备用位置保存数据。 使用 Azure 存储冗余选项（包括异地冗余存储（GRS）和异地区域冗余存储（GZRS）进一步将此数据复制到其他区域。 数据导出不会针对影响区域引入管道的事件提供复原能力。 如果需要 导出数据不支持的表导出，则可以使用其他导出数据的方法（包括 Azure 逻辑应用）来保护数据。 |
历史作日志数据可能无法在导出状态下轻松查询。 但是，它可确保数据在长时间的区域中断中幸存下来，并且可以长时间访问和保留数据。 |
| 对于任务关键型工作负荷，请考虑实现使用多个工作区的联合工作区模型，以便在发生区域性故障时提供高可用性。 若要实现此方法，请按照 Azure 上任务关键型工作负荷的运行状况建模和可观测性 中所述的指导作，了解如何在 Azure 上设计高度可靠的应用程序。 |
设计方法包括一个具有多个 Log Analytics 工作区的联合工作区模型，用于在发生多个故障（包括 Azure 区域的故障）的情况下提供高可用性。 此策略可消除跨区域的出口成本，并且工作负荷在发生区域故障期间仍可正常运行。 |
| 设计具有单个责任原则的 DCR，以简化 DCR 规则并最大程度地减少 DCR 中的转换，如 数据收集规则创建和管理的最佳做法中所述。 使用规则分配的组合来实现逻辑目标的所需可观测性范围。 |
使用以窄为中心的 DCR 时，它会最大程度地降低规则配置错误的风险，从而产生更广泛的影响。 它还将效果限制为仅生成 DCR 的范围。 在某些情况下，转换可能非常强大且必要，但测试和排查关键字查询语言（KQL）工作可能很困难。 |
| 配置 每日上限 设置，以防止失控引入，同时确保关键作数据收集继续。 设置高于典型每日引入量上限，并在接近容量时创建警报，以在关键数据收集停止之前进行调查。 建立符合故障排除和事件响应要求 的数据保留策略 。 此方法将关键日志类型保留足够的时间段，以支持根本原因分析。 |
每日上限通过防止错误配置中断快速事件响应所需的关键日志收集，帮助确保中断中断和事件期间基本故障排除数据的持续可用性。 适当的保留策略保持对有效根本原因分析、趋势识别和模式识别所需的历史作数据的访问权限，这些数据支持可靠的工作负荷作和更快的恢复平均时间。 |
| 使用 Log Analytics 工作区见解 跟踪引入量、引入的数据与数据上限、无响应日志源和失败查询以及其他数据。 创建 运行状况警报 ，以在工作区因数据中心或区域故障而不可用时主动通知你。 |
工作区见解有助于确保能够成功监视工作区的运行状况，并在工作负荷运行状况面临降级风险时主动采取行动。 与工作负荷的所有其他组件一样，了解运行状况指标并可以识别随时间推移提高可靠性的趋势至关重要。 |
安全性
安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。
安全设计原则通过对监视和日志记录解决方案的技术设计应用方法，为实现这些目标提供了高级设计策略。
工作负荷设计清单
根据 设计评审清单制定针对安全 的设计策略，并确定漏洞和控制，以增强安全防御能力。
查看安全最佳做法： 查看 Azure Monitor 安全基线中安全性 的最佳做法， 并管理对 Log Analytics 工作区文章的访问 。
以分段作为基石原则部署工作区： 在网络、数据和访问级别实现分段。 分段有助于确保工作区隔离到适当的程度。 它还有助于保护工作区免受对尽可能高的未经授权的访问，同时仍满足对可靠性、成本优化、卓越运营和性能效率的业务要求。
确保可以审核工作区读取和写入活动和关联的标识： 攻击者可以从查看作日志中获益。 泄露的标识可能导致日志注入攻击。 启用从 Azure 门户或通过 API 交互和关联用户运行的作的审核。
如果未设置为审核工作区，则可能使组织面临违反合规性要求的风险。
实现可靠的网络控制： 通过网络隔离和防火墙功能帮助保护对工作区和日志的网络访问。 配置不足的网络控制会增加未经授权的或恶意访问的风险。
确定数据类型需要不可变性或长期保留： 日志数据应与生产系统中的工作负荷数据相同。 在数据分类实践中包含日志数据，以确保根据符合性要求成功存储敏感数据。
通过加密保护静态日志数据： 单独分段不会完全保护日志数据的机密性。 如果发生未经授权的原始访问，加密静态日志数据有助于防止不良参与者在工作区外部使用该数据。
通过模糊处理保护敏感数据： 与驻留在生产系统中的工作负荷数据一样，必须采取额外措施，确保为可能有意或无意存在于作日志中的敏感信息保留机密性。 使用模糊处理方法时，它有助于隐藏敏感数据免受未经授权的访问。
配置建议
| 建议 | 益处 |
|---|---|
| 需要控制加密密钥时，使用 客户管理的密钥 来保护工作区中的数据和保存的查询。 客户管理的密钥需要一个具有足够数据量才能经济高效的 专用群集 。 将加密密钥存储在 Azure Key Vault 中，如果使用该服务，请考虑特定的 Microsoft Sentinel 要求 。 |
客户管理的密钥可控制密钥生命周期，并在法规或组织要求要求要求客户控制的加密时撤销对数据的访问权限。 |
| 配置 日志查询审核 以跟踪哪些用户正在运行的查询。 使用 Log Analytics 工作区见解 定期查看此数据。 请考虑创建日志查询警报规则，以便在未经授权的用户尝试运行查询时主动通知你。 |
查询审核记录工作区中运行的每个查询的详细信息，并通过确保发生未经授权的访问时立即捕获安全状况来增强安全态势。 |
| 使用 专用链接 功能将日志源与工作区之间的通信限制为专用网络。 | 专用链接提供网络隔离，并允许你控制哪些虚拟网络可以访问给定工作区。 此方法通过分段进一步增强安全性。 |
| 使用 Microsoft Entra ID ，而不是 API 密钥 ，以便在可用时访问工作区 API。 使用具有足够范围的Microsoft基于 Entra ID 的访问进行编程访问。 | Microsoft Entra ID 身份验证提供用于编程访问的按客户端审核线索，与基于 API 密钥的访问查询 API 不同。 |
| 将工作区的 访问控制模式 设置为 使用资源或工作区权限。 此访问控制允许资源所有者使用 资源上下文 访问其数据，而无需授予对工作区的显式访问权限。 对于需要跨多个资源访问一组表的用户，请使用 基于角色的访问控制（RBAC ）。 分配适当的 内置角色 ，根据其职责范围，在订阅、资源组或工作区级别向管理员授予工作区权限。 有关授予工作区中数据访问权限的各种选项的详细信息，请参阅 “管理对 Log Analytics 工作区 的访问权限”。 |
适当的访问控制模式配置简化了工作区配置，并帮助确保用户无法访问他们不应访问的作数据。 具有表权限的用户无论其资源权限如何，都可以访问表中的所有数据。 |
| 使用 数据导出 将数据发送到具有 不可变策略 的 Azure 存储帐户，以帮助防止数据篡改。 确定应根据符合性、审核或安全要求导出的特定数据类型，并根据需要 清除 数据。 |
具有不可变性策略的数据导出符合长期保留审核数据的合规性要求。 Log Analytics 工作区中的数据无法更改，但可以清除这些数据。 |
| 使用特定数据源的配置筛选不应收集的记录。 如果仅应删除或模糊处理数据中的特定列，请使用 转换 。 如果你有要求未修改原始数据的标准，则可以使用 KQL 查询中的 “h”文本 模糊化工作簿中显示的查询结果。 |
数据筛选和转换有助于确保对敏感信息保持机密性，并主动遵守要求。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。
成本优化设计原则为实现这些业务目标提供了高级设计策略。 它们还有助于在与监视和日志记录解决方案相关的技术设计中做出权衡。
工作负荷设计清单
根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
执行成本建模练习： 这些练习可帮助你了解当前的工作区成本，并预测与工作区增长相关的成本。 分析工作负荷中的增长趋势，并确保了解工作负荷扩展计划，以正确预测未来的运营日志记录成本。
选择正确的计费模型： 使用成本模型确定方案的最佳 计费模型 。 你当前如何使用工作区以及如何计划随着工作负荷的发展而使用工作区，确定即用即付还是承诺层模型最适合你的方案。
请记住，可以为每个工作区选择不同的计费模型。 还可以在特定情况下合并工作区成本，以便可以在分析和决策中细化。
仅收集正确的日志数据量： 对资源、数据收集规则配置和自定义应用程序代码日志记录执行诊断设置的定期计划分析，以确保不会收集不必要的日志数据。
以与生产环境不同的方式对待非生产环境： 查看非生产环境，确保正确配置诊断设置和保留策略。 这些设置和策略通常比生产环境中要低得多，尤其是对于开发/测试或沙盒环境。
配置建议
| 建议 | 益处 |
|---|---|
| 为每个 Log Analytics 工作区通常收集的数据量配置定价层。 如果收集足够的数据，请使用 承诺层 提交每日最低收集的数据，以换取较低的费率。 若要详细了解承诺层以及如何确定适当的使用级别，请参阅 Azure Monitor 日志成本计算和选项。 若要查看不同定价层使用情况的估计成本，请参阅 使用情况和估算成本。 |
与收集足够的每日数据量以满足最低承诺阈值相比，承诺层会显著降低成本。 |
| 如果在单个区域中的工作区中收集足够的数据，请将它们链接到 专用群集 ，并使用 群集定价合并收集的卷。 将群集配置为聚合来自多个工作区的引入卷，以实现经济高效的定价层。 |
在同一区域中有多个工作区时，具有群集定价的专用群集可大幅节省成本。 此设置允许你合并其数据量，以达到更高的承诺层并降低每千兆字节的引入成本。 |
| 配置 数据保留和存档。 请考虑让数据随时可用于日志查询的特定要求。 配置 存档日志 以将数据保留长达七年，并且仍会通过 搜索作业 或将 一组数据还原 到工作区来偶尔访问它。 |
数据保留和存档配置可大幅降低长期数据保留在默认时间段之外的成本，同时在需要时保持对历史数据的访问权限。 |
| 对大容量数据流使用摘要规则来优化存储成本。 摘要规则 允许跨分析、基本或辅助计划汇总高引入率流，从而提供汇总数据的可靠分析、仪表板和长期报告体验。 摘要规则启用自动数据汇总功能，可大幅降低大容量日志数据的存储成本，同时通过聚合数据集维护分析见解。 |
摘要规则通过创建分层数据体系结构来提供经济高效的长期数据保留，其中对高频率原始数据进行汇总，以便进行存储优化。 组织可以通过通过聚合数据集保持详细见解，同时优化长期数据保留费用，从而平衡成本效益与分析要求。 |
| 如果使用 Microsoft Sentinel 分析安全日志，请考虑使用单独的工作区来存储这些日志。 查看 Microsoft Sentinel 定价 以了解成本影响。 | 单独的工作区通过将受Microsoft Sentinel 定价的安全日志与按标准 Log Analytics 定价收取的作日志分开来帮助你控制成本。 |
| 将用于调试、故障排除和审核的表配置为 基本日志。 | 基本日志配置为不经常查询的表提供较低的引入成本，其中查询费用可以通过降低引入成本来抵消。 |
| 通过将 诊断设置 和 DCR 配置为仅收集基本作数据来捕获正确的数据量。 查看每个资源的数据源，以确保收集提供监视值的数据，同时避免不必要的数据。 有关配置指南 ，请参阅 Azure Monitor 中的成本优化 。 |
捕获正确的数据量可降低成本，方法是专注于作上有价值的数据，同时消除干扰。 此方法可确保捕获基本指标，而无需为不影响监视目标的数据付费。 |
| 定期分析工作区使用情况数据，以确定趋势和异常。 使用 Log Analytics 工作区见解 定期查看工作区中收集的数据量。 使用 Log Analytics 工作区中分析使用情况 的方法进一步分析数据收集，以确定其他配置是否可以进一步减少使用情况。 |
常规使用情况分析可帮助你了解跨各种源的数据收集、识别可能导致成本过剩的异常和上升趋势，并在引入新数据源时主动管理费用。 |
| 当数据收集量很高时创建警报。 为 过度使用设置主动通知。 | 通过高数据收集警报，可以在计费周期结束前解决潜在的异常情况，这有助于避免意外计费。 |
| 配置 每日上限 以防止因配置不当或滥用而导致失控引入，如 “何时使用每日上限”中所述。 创建警报，以在 达到上限 和 达到百分比时通知你，例如 90% 的容量。 |
每日上限配置提供针对意外预算溢出的保护，同时让你有机会在关闭关键数据收集之前调查和解决数据增加的原因。 |
卓越运营
卓越运营主要侧重于 开发实践、可观测性和发布管理的各个过程。
卓越运营设计原则 提供了一个高级设计策略，用于实现这些目标以满足工作负荷的作要求。
工作负荷设计清单
根据 针对卓越运营的设计评审清单 启动设计策略，以定义与 Log Analytics 工作区相关的可观测性、测试和部署过程。
对与工作负荷的 Log Analytics 工作区相关的所有函数使用基础结构即代码（IaC）： 通过通过代码自动执行尽可能多的这些函数，将手动管理和作日志收集、引入、存储和查询函数（包括已保存的查询和查询包）造成的人为错误风险降到最低。
此外，还包括报告运行状况更改的警报，以及将日志发送到 IaC 代码中工作区的资源的诊断设置配置。 将代码与其他工作负荷相关的代码包含在一起，以确保为工作区管理维护安全部署做法。
确保工作区正常运行，并在出现问题时收到通知： 与工作负荷的任何其他组件一样，工作区可能会遇到问题。 这些问题可能会消耗宝贵的时间和资源来诊断和修复，并且他们可能会让团队不知道生产工作负荷的状态。 主动监视工作区和早期问题缓解，使运营团队能够减少故障排除和修复所用的时间。
将生产与非生产工作负荷分开： 避免不必要的复杂性，这些复杂性可能会导致运营团队使用与非生产环境使用不同的工作区，从而为运营团队带来额外的工作。 由于测试活动似乎是生产中的事件，因此，传入的数据也可能导致混淆。
首选内置工具和函数而不是非Microsoft解决方案： 使用内置工具扩展监视和日志记录系统的功能。 可能需要设置额外的配置，以支持 Log Analytics 工作区中未现成可用的可恢复性或数据主权等要求。 在这些情况下，如果可行，请使用本机 Azure 或Microsoft工具，以最大程度地减少组织必须支持的工具数。
将工作区视为静态组件而不是临时组件： 与其他类型的数据存储一样，不应在工作负荷的临时组件中考虑工作区。 Well-Architected 框架通常支持不可变的基础结构，并能够在部署过程中快速轻松地替换工作负荷中的资源。 但工作区数据丢失可能是灾难性的且不可逆的。
因此，请将工作区从部署包中排除在更新期间替换基础结构的部署包，并且仅在工作区上执行就地升级。
确保针对 Kusto 查询语言训练作人员： 培训员工以在需要时创建或修改查询。 如果运算符无法写入或修改查询，则它可能会降低关键故障排除或其他函数的速度，因为操作员必须依赖其他团队来为它们执行该工作。
配置建议
| 建议 | 益处 |
|---|---|
| 设计 Log Analytics 工作区体系结构 以满足业务要求，包括要创建的工作区数以及放置位置。 如果工作负荷使用集中式平台团队产品/服务，请确保设置所有必要的作访问权限。 |
设计良好的工作区策略可限制运营和安全数据的分布，提高对潜在问题的可见性，使模式更易于识别，并最大程度地降低维护要求，从而最大程度地提高工作负荷的运营效率。 |
| 使用 IaC 模板（如 ARM 模板、 Bicep 或 Terraform）部署 Log Analytics 工作区。 在版本控制的模板中定义工作区配置和保存的查询。 为特定于环境的设置参数化模板，同时维护标准化的基线配置。 |
IaC 模板消除了环境之间的配置偏差，并通过一致的可重复过程减少部署错误。 版本控制支持更改跟踪，并为符合性要求简化审核线索。 |
| 实现持续集成和持续交付（CI/CD）管道，通过 Azure Pipelines 或 GitHub Actions 自动执行 Log Analytics 工作区部署。 集成自动化测试，在生产部署之前验证工作区配置。 将工作区基础结构代码与应用程序代码存储库并置，以应用一致的 安全部署做法。 |
自动化 CI/CD 管道可缩短部署时间，同时通过验证保持一致的质量。 安全部署做法将人为错误的风险降到最低，并在更新期间出现问题时提供回滚功能。 |
| 将 Azure Policy 与 Log Analytics 工作区的内置策略配合使用，强制实施工作区配置标准。 为组织特定的要求创建自定义策略，例如强制诊断设置和命名约定。 在适当的范围内实施策略分配，以自动将治理规则应用于新工作区并检测配置偏移。 |
策略强制实施可确保在所有工作区中保持一致的治理，而无需手动监督，从而减少运营开销。 自动合规性检查通过检测配置偏移来防止安全性和作问题。 通过策略实现标准化配置支持可缩放的工作区管理并启用一致的审核态势。 |
| 使用 Log Analytics 工作区见解 跟踪 Log Analytics 工作区的运行状况和性能。 查看 Log Analytics 工作区见解定期提供的信息，以跟踪每个工作区的运行状况和作。 根据 作表 创建警报规则，以在发生作问题时主动通知。 使用 工作区的建议警报 来简化创建最关键的警报规则的方式。 |
Log Analytics 工作区见解提供所有工作区的使用情况、性能、运行状况、代理、查询和更改日志的统一视图。 使用 Log Analytics Workspace Insights 可以创建易于理解的可视化效果，例如运营团队和利益干系人可用于跟踪工作区运行状况的仪表板或报表。 |
| 通过频繁重新访问资源、DCR 和应用程序日志详细程度来练习持续改进。 确保通过频繁评审资源设置来优化日志收集策略。 从作的角度来看，通过专注于那些提供有关资源运行状况的有用信息的日志来减少日志中的干扰。 |
持续改进做法可帮助操作员调查和解决问题，并在问题发生时处理日常、即兴或紧急任务。 这些做法还通过专注于对运营团队进行跟踪最重要的活动来减少日志量。 |
性能效率
性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 此策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。
性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。
工作负荷设计清单
根据性能效率设计评审清单开始设计策略。 定义基于 Log Analytics 工作区的关键绩效指标的基线。
熟悉 Azure Monitor 中日志数据引入延迟的基础知识： 在将日志引入工作区时，有几个因素会导致延迟。 其中许多因素固有于 Azure Monitor 平台。
了解因素和正常的延迟行为有助于在工作负荷运营团队中设置适当的预期。
将非生产工作负荷和生产工作负荷分开： 生产特定的工作区可缓解非生产系统可能引入的任何开销。 分离可减少工作区的总体占用空间，只需减少资源来处理日志数据处理。
选择适当的部署区域以满足性能要求： 部署靠近工作负荷的 Log Analytics 工作区和 DCE。 在何处部署工作负荷时，应通知你选择在其中部署工作区和 DCE 的相应区域。
如果已将工作负荷部署到不支持日志数据的这些要求的区域，可能需要根据可靠性要求来权衡在与工作负荷相同的区域中部署工作区和 DCE 的性能优势。
配置建议
| 建议 | 益处 |
|---|---|
| 配置 日志查询审核 并使用 Log Analytics Workspace Insights 来识别缓慢和低效的查询。 有关如何提高慢速日志查询性能的指导，请参阅 Azure Monitor 中的优化日志查询 。 |
优化查询更快地返回结果，并在后端使用更少的资源，这也使依赖于这些查询的进程更高效。 |
| 对大型数据集和长期保留数据使用搜索作业进行复杂的分析查询。 搜索作业 是在 Log Analytics 工作区中的任何数据上运行的异步查询，包括长期保留期中的数据。 搜索作业在工作区中创建新的 Analytics 表，使结果可用于进一步查询。 此功能使分析工作负荷与作监视分离，从而提高系统性能，同时保持全面的数据访问。 |
搜索作业支持复杂的历史数据分析，而不会影响实时监视性能。 它们通过最少的资源冲突启用专用分析处理，使安全团队和分析师能够对存档数据运行密集查询，同时保持作监视响应能力。 |
| 查看 Azure Monitor 服务限制 和 Log Analytics 工作区 限制，了解可能影响性能和工作区设计的限制。 适当设计以缓解服务限制，这可能需要使用多个工作区以避免达到与单个工作区关联的限制。 |
了解可能影响工作区性能的限制有助于进行适当的设计，以缓解这些限制，并平衡针对其他支柱的要求和目标的设计决策。 |
| 在一个或多个定义的可观测性范围内创建特定于数据源类型的 DCR 。 为性能和事件创建单独的 DCR，以优化后端处理计算使用情况。 |
用于性能和事件的独立 DCR 有助于缓解后端资源耗尽，并防止过度的计算资源消耗，这可能导致 Azure Monitor 代理无响应。 |
Azure 策略
Azure 提供了一组与 Log Analytics 及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下控件是否已到位：
Log Analytics 群集使用客户管理的密钥进行加密。
保存的查询存储在客户存储帐户中，用于加密。
Log Analytics 工作区阻止非Microsoft基于条目 ID 的引入。
Log Analytics 工作区阻止从公用网络进行日志引入和查询。
为安全访问正确实现了专用链接配置。
若要进行全面的治理，请查看 Log Analytics 的 Azure Policy 内置定义 ，以及可能影响监视和日志记录基础结构安全性的其他策略。
Azure 顾问建议
Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。
有关详细信息，请参阅 顾问。