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