Azure Monitor 中的卓越运营最佳做法
卓越运营是指使服务在生产环境中可靠运行所需的操作流程。 使用以下信息将监视虚拟机的操作要求降到最低。
本文介绍 Azure Monitor 的卓越运营，它属于 Azure 架构良好的框架。 Azure 架构良好的框架是一组指导原则，可用于提高工作负荷的质量。 该框架包含卓越体系结构的五大要素：
- 可靠性
- 安全性
- 成本优化
- 卓越运营
- 性能效率
Azure Monitor 日志
设计清单
- 设计具有最少数量的工作区的工作区体系结构，以满足业务要求。
- 管理多个工作区时，使用基础结构即代码 (IaC)。
- 使用 Log Analytics 工作区见解跟踪 Log Analytics 工作区的运行状况和性能。
- 创建警报规则，以主动接收工作区中操作问题的通知。
- 确保有定义明确的运营流程用于数据隔离。
配置建议
| 建议 | 好处 |
|---|---|
| 设计工作区策略以满足业务要求。 | 请参阅设计 Log Analytics 工作区体系结构，获取有关为 Log Analytics 工作区设计策略的指导，包括创建数量和放置位置。 单个或至少最少数量的工作区将最大程度地提高运营效率，因为它会限制运营和安全数据的分布，提高对潜在问题的可见性，使模式更易于识别，并最大程度地降低维护要求。 你可能对多个工作区（例如多个租户）有要求，或者可能需要多个区域中的工作区以支持可用性要求。 在这些情况下，请确保有适当的流程来管理这种增加的复杂性。 |
| 管理多个工作区时，使用基础结构即代码 (IaC)。 | 使用基础结构即代码 (IaC) 定义ARM、BICEP或Terraform中工作区的详细信息。 这样就可以利用现有的 DevOps 流程以部署新工作区和Azure Policy以强制执行其配置。 |
| 使用 Log Analytics 工作区见解跟踪 Log Analytics 工作区的运行状况和性能。 | Log Analytics 工作区见解提供了工作区使用情况、性能、运行状况、代理、查询和更改日志的统一视图。 定期查看此信息以跟踪每个工作区的运行状况和操作。 |
| 创建警报规则，以主动接收工作区中操作问题的通知。 | 每个工作区都有一个操作表，用于记录影响工作区的重要活动。 基于此表创建警报规则，以在发生操作问题时主动接收通知。 可以使用针对工作区的建议警报，以简化最关键警报规则的创建。 |
| 确保有定义明确的运营流程用于数据隔离。 | 对于工作区中存储的不同类型的数据，可能有不同的要求。 在设计工作区策略以及配置权限和长期保留等设置时，请确保清楚了解数据保留和安全性等要求。 还应该有明确定义的流程，以偶尔清除数据，其中包括意外收集的个人信息。 |
警报
设计清单
- 在适当的情况下，在指标警报规则中使用动态阈值。
- 尽可能使用一个警报规则来监控多个资源。
- 若要大规模控制行为，请使用警报处理规则。
- 利用自定义属性增强诊断
- 利用逻辑应用自定义、扩充和集成各种系统
配置建议
| 建议 | 好处 |
|---|---|
| 在适当的情况下，在指标警报规则中使用动态阈值。 | 你可能不确定要用作警报规则阈值的正确数字。 动态阈值使用机器学习，并使用一组算法和方法根据趋势确定正确的阈值，因此无需提前了解正确的预定义阈值。 动态阈值也可用于监视多个资源的规则，并且无法为所有资源配置单个阈值。 请参阅指标警报中的动态阈值。 |
| 尽可能使用一个警报规则来监控多个资源。 | 使用监视多个资源的警报规则可以通过管理一个规则来监视大量资源，从而减少管理开销。 |
| 若要大规模控制行为，请使用警报处理规则。 | 警报处理规则可用于减少需要创建和管理的警报规则数。 |
| 使用自定义属性增强诊断。 | 如果警报规则使用操作组，你可以添加自己的属性以包含在警报通知负载中。 可以在操作组调用的操作（如 Webhook、Azure 函数或逻辑应用操作）中使用这些属性。 |
虚拟机
设计清单
- 从旧版代理程序迁移到 Azure Monitor 代理。
- 使用 Azure Arc 在 Azure 外部监视 VM。
- 使用 Azure Policy 部署代理并分配数据收集规则。
- 建立适用于数据收集规则结构的策略。
配置建议
| 建议 | 说明 |
|---|---|
| 从旧版代理程序迁移到 Azure Monitor 代理。 | 与旧版 Log Analytics 代理相比，Azure Monitor 代理更易于管理，并允许更加灵活地进行 Log Analytics 工作区设计。 Windows 和 Linux 代理允许多宿主，这意味着它们可以连接到多个工作区。 数据收集规则支持大规模管理数据收集设置，并为计算机的子集定义限定范围的唯一配置。 有关考虑事项和迁移方法，请参阅从 Log Analytics 代理迁移到 Azure Monitor 代理。 |
| 使用 Azure Arc 在 Azure 外部监视 VM。 | 使用适用于服务器的 Azure Arc，可以管理托管在 Azure 以外、公司网络或其他云提供商的物理服务器和虚拟计算机。 通过 Azure 连接计算机代理，可以使用适用于 Azure VM 的同一方法将 Azure Monitor 代理部署到这些 VM，然后使用相同的 Azure Monitor 工具监视整个 VM 集合。 |
| 使用 Azure Policy 部署代理并分配数据收集规则。 | 借助 Azure Policy，可以将代理自动部署到现有 VM 集和所创建的任何新 VM。 此操作可确保在管理员干预最少的情况下监视所有 VM。 如果要在没有 VM 见解的情况下管理 Azure Monitor 代理，请参阅使用 Azure Policy 启用 Azure Monitor 代理。 有关创建数据收集规则关联的模板，请参阅请参阅[在 Azure Monitor 中管理数据收集规则关联](../essentials/data-collection-rule-associations.md#create-new-association)。 |
| 建立适用于数据收集规则结构的策略。 | 数据收集规则使用 Azure Monitor 代理定义要从虚拟机收集的数据以及将数据发送到何处。 每个 DCR 可以包含多个收集方案，并与任意数量的 VM 相关联。 建立配置 DCR 的策略，以仅为不同 VM 组收集所需数据，同时在最大程度上减少需要管理的 DCR 数。 |
容器
设计清单
- 查看有关监视 Kubernetes 环境所有层的指南。
- 使用已启用 Azure Arc 的 Kubernetes 来监视 Azure 外部的群集。
- 将 AKS 群集集成到现有的监视工具中。
- 使用 Azure policy 启用从 Kubernetes 群集收集数据。
配置建议
| 建议 | 好处 |
|---|---|
| 查看有关监视 Kubernetes 环境所有层的指南。 | 使用容器见解监视 Kubernetes 群集性能，包括从网络、群集和应用程序层监视整个 Kubernetes 环境的指南和最佳做法。 |
| 使用已启用 Azure Arc 的 Kubernetes 来监视 Azure 外部的群集。 | 已启用 Azure Arc 的 Kubernetes 允许使用与 AKS 群集相同的工具（包括容器见解）来监视在其他云中运行的 Kubernetes 群集。 |
| 将 Azure 托管服务用于云原生工具。 | 适用于 Prometheus 和 Azure 托管 Grafana 的 Azure Monitor 托管服务支持云原生工具 Prometheus 和 Grafana 的所有功能，而无需操作其底层基础结构。 可以以尽量小的开销快速预配这些工具并载入 Kubernetes 群集。 通过这些服务，可以访问大量社区规则和仪表板库，以监视 Kubernetes 环境。 |
| 将 AKS 群集集成到现有的监视工具中。 | 如果已经在 Prometheus 和 Grafana 有所投入，请使用使用 Azure 服务和云原生工具监视 Kubernetes 群集中的指南，将 AKS 群集和 Azure 托管服务集成到现有环境中。 |
| 使用 Azure policy 启用从 Kubernetes 群集收集数据。 | 使用 Azure Policy 启用数据收集，以便启用 Prometheus 指标、容器见解和诊断设置。 这可确保自动监视任何新群集并强制实施其监视配置。 |