Azure 上任务关键型工作负荷的运行状况建模和可观测性

运行状况建模和可观测性是最大化可靠性的基本概念，侧重于坚固且上下文相关的仪表化和监视。 这些概念提供对应用程序运行状况的关键见解，促进问题的快速识别和解决。

大多数任务关键型应用程序在规模和复杂性方面都非常重要，因此会生成大量作数据，这使得评估并确定最佳作作具有挑战性。 运行状况建模的最终目标是通过增强原始监控日志和指标，并结合关键业务需求，来量化应用程序的运行状况，从而最大化可观测性。这推动了运行状况状态的自动化评估，以实现操作的一致性和加速。

此设计领域侧重于定义一个稳健的健康模型的过程，通过可观测性和运营构造映射量化的应用程序健康状态，以实现运营成熟度。

努力提高可靠性时，运营成熟度有三个主要级别。

1. 检测 和响应实时发生的问题。
2. 诊断 发生或已发生的问题。
3. 预测 和防止问题发生之前。

视频：为任务关键型工作负荷定义运行状况模型

分层应用程序运行状况

若要构建运行状况模型，请先通过在关键业务需求的上下文中定义应用程序运行状况，方法是以分层且可度量的格式量化“健康”和“不正常”状态。 然后，对于每个应用程序组件，在稳定运行状态的上下文中优化定义，并根据应用程序用户流进行聚合。 将关键的非功能性业务需求与性能和可用性要求结合起来。 最后，聚合每个用户流的运行状况状态，形成整体应用程序运行状况的可接受表示形式。 一旦建立，应使用这些分层健康定义来告知所有系统组件的关键监视指标，并验证操作子系统的组成。

设计注意事项

• 建模运行状况的过程是一项自上而下的设计活动，从体系结构练习开始，定义所有用户流，并映射功能组件与逻辑组件之间的依赖关系，从而隐式映射 Azure 资源之间的依赖关系。

• 健康模型完全依赖于它所代表的解决方案的上下文，因此不能开箱即用，因为一刀切的方案并不适用。

  • 应用程序在组合和依赖项方面会有所不同
  • 还必须根据表示正常和不正常状态的值对资源的指标和指标阈值进行微调，这些状态受包含的应用程序功能和目标非功能要求的影响很大。

• 分层运行状况模型使应用程序运行状况能够追溯到较低级别的依赖项，这有助于快速导致服务降级。

• 若要捕获单个组件的健康状态，必须在反映生产负载的稳定状态下了解该组件独特的运行特征。 因此，性能测试是定义和持续评估应用程序运行状况的关键功能。

• 云解决方案中的故障可能不会隔离发生。 单个组件的中断可能会导致多个功能或其他组件变得不可用。

  • 此类错误可能无法立即观察到。

设计建议

• 将可衡量的运行状况模型定义为一个优先级，以确保对整个应用程序的明确作理解。

  • 健康模型应分层，并能够反映应用程序的结构。
  • 基础层应考虑单个应用程序组件，例如 Azure 资源。
  • 基础组件应与关键非功能需求一起整合，以构建一种业务视角来审视系统流的健康状况。
  • 系统流应根据业务关键性使用适当的权重进行聚合，以生成对整体应用程序运行状况有意义的定义。 财务上具有重要影响或面向客户的用户流程应优先处理。
  • 运行状况模型的每个层都应捕获“正常”和“不正常”状态表示的内容。
  • 确保健康模型可以区分瞬态和非瞬态性不正常状态，以隔离服务降级与不可用的情况。

• 使用每个不同应用程序组件的精细运行状况分数和每个用户流来表示运行状况状态，方法是聚合映射依赖组件的运行状况分数，并将关键非功能要求视为系数。

  • 用户流的健康分数应表示为所有映射组件中的最低分数，同时考虑与用户流的非功能性需求相关的相对实现。
  • 用于计算运行状况分数的模型必须一致地反映作运行状况，如果不是，则应调整并重新部署模型以反映新的学习。
  • 定义健康分数阈值以反映状态。

• 运行状况分数必须基于基础指标自动计算，这些指标可以通过可观测性工具进行可视化，并通过自动化操作程序执行。

  • 运行状况分数应成为监视解决方案的核心，以便运营团队不再需要解释作数据并将其映射到应用程序运行状况。

• 使用健康模型来计算可用性服务级别目标（SLO）的实现，而不是直接以原始可用性为基础，以确保服务降级与不可用之间的划分作为单独的 SLO 得以体现。

• 在 CI/CD 管道和测试周期中使用健康模型，以验证在代码和配置更新后是否维持应用程序的健康状态。

  • 运行状况模型应用于在负载测试和混沌测试期间观察和验证运行状况，作为 CI/CD 过程的一部分。

• 构建和维护运行状况模型是一个迭代过程，工程投资应与推动持续改进保持一致。

  • 定义一个过程，以持续评估和微调模型的准确性，并考虑投资机器学习模型来进一步训练模型。

示例 - 分层健康模型

这是分层应用程序运行状况模型的简化表示形式，用于说明目的。 Mission-Critical 参考实现中提供了全面且具有情境化的健康模型：

• Mission-Critical Online
• 已连接Mission-Critical

实现运行状况模型时，必须通过关键资源级指标的聚合和解释来定义各个组件的运行状况。 下面显示了如何使用资源指标的示例：

此运行状况定义随后可由 KQL 查询表示，如下例查询所示，该查询聚合 InsightsMetrics（容器见解）和 AzureMetrics（AKS 群集的诊断设置），并将（内部联接）与建模的运行状况阈值进行比较。

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

生成的表格输出随后可以转换为健康得分，以便更便捷地在更高层级的健康模型中进行聚合。

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

随后可以使用可视化工具（如 Grafana）将这些聚合分数表示为依赖项图表，以演示运行状况模型。

此图显示了 Azure Mission-Critical 联机参考实现中的一个分层运行状况模型示例，并演示基础组件的运行状况状态更改如何对用户流和整体应用程序运行状况产生级联影响（示例值对应于上图中的表）。

演示视频：监视和运行状况建模演示

用于关联分析的统一数据接收器

必须从所有系统组件收集许多运行数据集，以准确表示定义的健康模型，并考虑来自应用程序组件和基础 Azure 资源的日志和指标。 这种海量数据最终需要以允许近实时处理的格式进行存储，以便于迅速采取行动。 此外，需要确保跨所有包含的数据集具有相关性，以保证有效分析没有限制，从而支持健康的分层表示形式。

需要一个统一的数据汇聚点，以确保能够迅速存储所有操作数据，并使其可用于相关分析，从而生成应用程序运行状况的“单一视图”表示。 Azure 提供了多种不同的运营技术，这些技术都属于 Azure Monitor 旗下，而 Log Analytics 工作区作为核心 Azure 原生数据存储，用于存储和分析运营数据。

设计注意事项

Azure Monitor

• 默认情况下，为所有 Azure 订阅启用 Azure Monitor，但必须部署 Azure Monitor 日志（Log Analytics 工作区）和 Application Insights 资源并将其配置为合并数据收集和查询功能。

• Azure Monitor 支持三种类型的可观测性数据：日志、指标和分布式跟踪。

  • 日志存储在 Log Analytics 工作区中，该工作区基于 Azure 数据资源管理器。 日志查询存储在可跨订阅共享的查询包中，用于驱动可观测性组件，例如仪表板、工作簿或其他报告和可视化工具。
  • 指标存储在内部时序数据库中。 对于大多数 Azure 资源，指标会自动收集和 保留 93 天。 还可以使用资源的 诊断设置 将指标数据发送到 Log Analytics 工作区。

• 所有 Azure 资源都会公开日志和指标，但必须适当配置资源，以便将诊断数据路由到所需的数据接收器。

• 监管控制要求运营数据保留在原始地理位置或国家/地区的情况并不罕见。 法规要求可以规定长期保留关键数据类型。 例如，在受监管的银行业务中，审核数据必须至少保留七年。

• 不同的操作数据类型可能需要不同的保留期。 例如，安全日志可能需要长期保留，而性能数据不太可能需要在 AIOps 上下文之外长期保留。

• 数据可以 存档 或 导出 到 Log Analytics 工作区，以便长期保留和/或审核。

• 专用群集 提供部署选项，使可用性区域免受受支持 Azure 区域中的区域性故障的保护。 专用群集需要最低每日数据引入承诺。

• Log Analytics 工作区部署到指定的 Azure 区域。

• 为了防止 Log Analytics 工作区不可用而丢失数据，可以使用多个诊断设置来配置资源。 每个诊断设置都可以将指标和日志发送到单独的 Log Analytics 工作区。

  • 发送到每个额外的 Log Analytics 工作区的数据会产生额外的费用。
  • 冗余的 Log Analytics 工作区可以部署到同一 Azure 区域，也可以部署到单独的 Azure 区域，以便实现其他区域冗余。
  • 将日志和指标从 Azure 资源发送到不同区域中的 Log Analytics 工作区会产生区域间数据出口成本。
  • 某些 Azure 资源需要与资源本身位于同一区域中的 Log Analytics 工作区。
  • 有关 Log Analytics 工作区的进一步可用性选项，请参阅 Azure Monitor 日志的最佳做法 。

• Log Analytics 工作区数据 可以连续、计划或一次性导出到 Azure 存储或 Azure 事件中心。

  • 数据导出允许长期数据存档，并保障防止由于数据不可用造成的数据丢失。
  • 可用的导出目标为 Azure 存储或 Azure 事件中心。 Azure 存储可以配置为不同的 冗余级别，包括可用区级别或区域级别。 数据导出到 Azure 存储会将数据存储在 .json 文件中。
  • 数据导出目标必须与 Log Analytics 工作区位于同一 Azure 区域中。 事件中心数据导出的目标应位于与 Log Analytics 工作区相同的区域。 Azure 事件中心异地灾难恢复不适用于此方案。
  • 存在多个 数据导出限制。 工作区中仅支持特定表进行数据导出。
  • 存档 可用于在 Log Analytics 工作区中存储数据，以便以更低的成本长期保留数据，而无需导出数据。

• Azure Monitor 日志具有 用户查询节流限制，这些限制可能会导致客户端可用性降低，例如在可观测性仪表板中。

  • 每个用户有五个并发查询：如果已运行 5 个查询，则在运行查询结束之前，其他查询将放置在每用户并发队列中。
  • 并发队列中的时间：如果查询位于并发队列中超过三分钟，它将终止，并返回 429 错误代码。
  • 并发队列深度限制：并发队列限制为 200 个查询，其他查询将被拒绝，错误代码为 429。
  • 查询速率限制：所有工作区中每 30 秒的每用户限制为 200 个查询。

• 查询包 是 Azure 资源管理器资源，可用于在 Log Analytics 工作区不可用时保护和恢复日志查询。

  • 查询包包含 JSON 形式的查询，并且可以存储在 Azure 外部，类似于其他基础结构即代码资产。
    • 可通过 Microsoft.Insights REST API 进行部署。
    • 如果必须重新创建 Log Analytics 工作区，则可以从外部存储的定义重新部署查询包。

• Application Insights 可以部署在基于工作区的部署模型中，该部署模型由存储所有数据的 Log Analytics 工作区提供支持。

• 可以在 Application Insights 中启用采样，以减少发送的遥测量并优化数据引入成本。

• Azure Monitor 收集的所有数据（包括 Application Insights）根据引入的数据量和保留数据的持续时间 收费 。

  • 数据引入到 Log Analytics 工作区后，最多可保留不超过 31 天（如果启用了 Sentinel，则可保留最多 90 天）。
  • 引入到基于工作区的 Application Insights 中的数据将保留最初的 90 天，无需额外费用。

• Log Analytics 承诺层定价模型提供更低的成本和可预测的数据引入费用方法。

  • 预留级别以上的任何使用量按与当前层相同的价格计费。

• Log Analytics、Application Insights 和 Azure 数据资源管理器使用 Kusto 查询语言 （KQL）。

• Log Analytics 查询保存为 Log Analytics 工作区中的 函数 （savedSearches）。

设计建议

• 使用 Log Analytics 工作区作为统一的数据接收器，为所有操作数据集提供一个统一视图。

  • 跨所有已用部署区域分散 Log Analytics 工作区。 每个具有应用程序部署的 Azure 区域都应考虑使用 Log Analytics 工作区来收集源自该区域的所有作数据。 所有全局资源都应使用单独的专用 Log Analytics 工作区，该工作区应在主要部署区域中部署。
    • 将所有操作数据发送到单个 Log Analytics 工作区将导致单点故障。
    • 数据驻留的要求可能会禁止数据离开原始区域，并且联合工作区默认解决了此要求。
    • 与跨区域传输日志和指标相关的显著出口成本。
  • 同一区域中的所有部署标记都可以使用相同的区域 Log Analytics 工作区。

• 请考虑配置具有多个诊断设置的资源，这些设置指向不同的 Log Analytics 工作区，以防止使用更少的区域部署标记的应用程序无法使用 Azure Monitor。

• 在所有应用程序组件中使用 Application Insights 作为一致的应用程序性能监视（APM）工具来收集应用程序日志、指标和跟踪。

  • 在基于工作区的配置中部署 Application Insights，以确保每个区域 Log Analytics 工作区都包含来自应用程序组件和基础 Azure 资源的日志和指标。

• 使用 跨工作区查询 跨不同的工作区维护统一的“单窗格”。

• 使用 查询包 在工作区不可用时保护日志查询。

  • 将查询包作为基础结构即代码资产存储在应用程序 git 存储库中。

• 所有 Log Analytics 工作区都应被视为运行时间较长的资源，其生命周期与区域部署戳中的应用程序资源不同。

• 从 Log Analytics 工作区导出关键操作数据以实现长期保留和分析，促进 AIOps 和高级分析，以优化基础运行状况模型并指导预测行动。

• 仔细评估哪些数据存储应用于长期保留;并非所有数据都必须存储在热和可查询的数据存储中。

  • 强烈建议将 Azure 存储配置为 GRS 用于长期的操作性数据存储。
    • 使用 Log Analytics 工作区导出功能将所有可用的数据源导出到 Azure 存储。

• 为日志分析中的操作数据类型选择适当的保留期，并在存在“热”可观测性需求的工作区中配置更长的保留期。

• 使用 Azure Policy 确保所有区域资源将运营数据路由到正确的 Log Analytics 工作区。

• 仅在需要优化性能或者采样以控制成本时，才在 Application Insights 中配置采样。

  • 过度采样可能会导致作信号缺失或不准确。

• 对所有跟踪事件和日志消息使用关联 ID，以将它们绑定到给定的请求。

  • 为所有调用（而不仅仅是失败的请求）将关联 ID 返回到调用方。

• 确保应用程序代码包含适当的检测和日志记录，以通知运行状况模型，并在需要时促进后续故障排除或根本原因分析。

  • 应用程序代码应使用 Application Insights 来简化 分布式跟踪，方法是向调用方提供全面的错误消息，其中包括发生故障时的关联 ID。

• 对所有日志消息使用 结构化日志记录 。

• 向所有应用程序组件添加有意义的运行状况探测。

  • 使用 AKS 时，为每个部署（pod）配置运行状况终结点，以便 Kubernetes 可以正确确定 Pod 是否正常或运行不正常。
  • 使用 Azure 应用服务时，配置 运行状况检查 ，以避免横向扩展操作因将流量发送到尚未就绪的实例而导致错误，并确保对不健康的实例进行快速回收。

如果应用程序订阅了“Microsoft Mission-Critical Support”，请考虑向 Microsoft 支持公开关键运行状况探测，以便 Microsoft 支持能够更精确地分析应用程序运行状况。

• 记录成功的运行状况检查请求，除非应用程序性能上下文中无法容忍增加的数据量，因为它们为分析建模提供了其他见解。

• 不要将生产 Log Analytics 工作区配置为应用 每日上限，因为这会限制运营数据的每日摄取，从而可能导致关键运营数据丢失。

  • 在较低环境中（如开发和测试），每日上限可以被视为可选的成本节省机制。

• 提供的操作数据引入量如果满足最低层次阈值，请配置 Log Analytics 工作区，使用承诺层定价，以实现相对于“即用即付”定价模型的成本效益。

• 强烈建议使用源代码管理存储 Log Analytics 查询，并使用 CI/CD 自动化将其部署到相关的 Log Analytics 工作区实例。

可视化

通过可视化展示包含关键运营数据的健康模型，对于实现有效运营和最大化可靠性至关重要。 最终应利用仪表板为 DevOps 团队提供近乎实时的见解，以便快速诊断偏离稳定状态的问题。

Microsoft提供了多种数据可视化技术，包括 Azure 仪表板、Power BI 和 Azure 托管 Grafana（目前为预览版）。 Azure 仪表板旨在为 Azure Monitor 中的运维数据提供无缝集成的开箱即用可视化解决方案。 因此，它在任务关键型工作负载的操作数据和应用程序健康状况的可视化表示中起着根本作用。 但是，在将 Azure 仪表板定位为整体可观测性平台方面存在一些限制，因此应考虑补充使用市场领先的可观测性解决方案，例如 Grafana，后者也作为 Azure 中的托管解决方案提供。

本部分重点介绍如何使用 Azure 仪表板和 Grafana 构建坚实的仪表板体验，以从技术和业务视角提供对应用程序运行状况的深入了解，从而支持 DevOps 团队并促进高效运作。 可靠的仪表盘对于诊断已经发生的问题至关重要，并支持运营团队在问题出现时进行检测和响应。

设计注意事项

• 当使用日志查询可视化健康模型时，请注意，并发查询、排队查询以及总体查询速率均受到 Log Analytics 的限制，后续的查询将排队并被限制。

• 可以在 Log Analytics 或 Azure 数据资源管理器中编写和执行用于计算和表示健康评分的运营数据查询。

  • 此处提供了示例查询。

• Log Analytics 施加了多个 查询限制，在设计操作仪表板时必须考虑这些限制。

• 原始资源指标（如 CPU 利用率或网络吞吐量）的可视化需要运营团队手动评估以确定运行状况影响，这在活动事件期间可能很困难。

• 如果多个用户使用 Grafana 等工具中的仪表板，则发送到 Log Analytics 的查询数会迅速增加。

  • 达到 Log Analytics 并发查询限制将排队后续查询，使仪表板体验变得‘缓慢’。

设计建议

• 收集和显示来自所有区域 Log Analytics 工作区和全局 Log Analytics 工作区的查询输出，以生成应用程序运行状况的统一视图。

• 应使用“交通灯”模型直观地表示“健康”和“不正常”状态，绿色用于说明何时完全满足关键非功能要求，并充分利用资源。 使用“绿色”、“琥珀色”和“红色”来表示“正常”、“已降级”和“不可用”状态。

• 使用 Azure 仪表板为全球资源和区域部署标记创建运营透视视图，展示关键指标，例如 Azure Front Door 的请求计数、Azure Cosmos DB 的服务器端延迟、Event Hubs 的消息流入/流出，以及 AKS 的 CPU 使用率或部署状态。 应针对仪表板进行定制，以提高运营效率，从故障方案中注入学习，以确保 DevOps 团队能够直接了解关键指标。

• 如果 Azure 仪表板不能用于准确表示运行状况模型和必要的业务需求，则强烈建议将 Grafana 视为替代可视化解决方案，提供市场领先的功能和广泛的开源插件生态系统。 评估托管的 Grafana 预览服务，以避免管理 Grafana 基础结构的复杂性。

• 部署自托管 Grafana 时，请采用高可用性和异地分布式设计，以确保关键操作仪表板能够抵御区域平台故障和级联错误场景。

  • 将配置状态分隔到外部数据存储（例如 Azure Database for Postgres 或 MySQL）中，以确保 Grafana 应用程序节点保持无状态。

    • 在部署区域之间配置数据库复制。

  • 使用基于容器的部署，在一个区域内将 Grafana 节点以高可用配置部署到应用服务中。

    • 跨已考虑的部署区域部署应用服务实例。

    应用服务提供了一个低摩擦的容器平台，这非常适合低规模场景，例如操作仪表板。将 Grafana 与 AKS 隔离在不同的环境中，能够明确划分主要应用平台与该平台的操作表示形式之间的关注点。 有关进一步的配置建议，请参阅“应用程序平台注销”区域。

  • 在 GRS 配置中使用 Azure 存储来托管和管理自定义视觉对象和插件。

  • 将应用服务和数据库只读副本的 Grafana 组件部署到至少两个部署区域，并考虑采用将 Grafana 部署到所有考虑的部署区域的方案。

对于目标 >= 99.99% SLO 的场景，Grafana 应部署在至少 3 个部署区域中，以最大程度地提高关键操作仪表板的整体可靠性。

• 通过将查询聚合到单个或少量查询（例如使用 KQL“union”运算符）并在仪表板上设置适当的刷新速率来缓解 Log Analytics 查询限制。

  • 适当的最大刷新率取决于仪表板查询的数量和复杂性;需要对已实现的查询进行分析。

• 如果达到了 Log Analytics 的并发查询限制，请考虑通过将仪表板所需的数据存储（临时）存储到高性能数据存储（例如 Azure SQL）来优化检索模式。

自动事件响应

虽然应用程序运行状况的可视表示形式提供了宝贵的作和业务见解来支持问题检测和诊断，但它依赖于运营团队的准备情况和解释，以及后续人为触发的响应的有效性。 因此，若要最大程度地提高可靠性，必须实施广泛的警报，以主动检测并近乎实时地响应问题。

Azure Monitor 提供了广泛的警报框架，用于通过 操作组检测、分类和响应操作信号。 因此，本部分将重点介绍如何使用 Azure Monitor 警报来推动自动化操作，以响应当前或潜在的偏离健康应用程序状态的情况。

设计注意事项

• 当传入信号满足条件时，将定义警报规则以触发，信号可以包括各种 数据源，例如度量、日志查询或可用性测试。

• 可以在特定资源的 Log Analytics 或 Azure Monitor 中定义警报。

• 某些指标仅在 Azure Monitor 中可询问，因为 Log Analytics 中并非所有诊断数据点都可用。

• Azure Monitor 警报 API 可用于检索活动警报和历史警报。

• 存在与警报和作组相关的订阅限制，这些限制必须设计为：

  • 可配置警报规则的数量存在限制。
  • 警报 API 具有速率限制，对于极端使用方案，应予以考虑限制。
  • 作组对可配置响应的数量有 若干硬性限制 ，必须针对这些响应进行设计。
    • 每个响应类型都有 10 个操作的限制，除了电子邮件，限制为 1,000 个操作。

• 可以通过从模型的“根”评分函数为保存的日志搜索查询创建警报规则，从而在分层运行状况模型中集成警报。 例如，使用“WebsiteHealthScore”并针对表示“不正常”状态的数值发出警报。

设计建议

• 对于以资源为中心的警报，请在 Azure Monitor 中创建警报规则，以确保所有诊断数据都可用于警报规则条件。

• 将自动化操作合并到最少数量的操作组中，以与服务团队协同配合，从而支持 DevOps 方法。

• 通过自动化缩放操作响应过度资源利用信号，并尽可能使用 Azure 本机自动缩放功能。 如果内置自动缩放功能不适用，请使用组件健康评分对信号进行建模，以确定何时启动自动缩放操作。 确保根据容量模型定义自动化缩放操作，该模型量化组件之间的缩放关系，以便缩放响应涵盖需要根据其他组件进行缩放的组件。

• 为了适应由业务影响决定的优先级顺序，调整模型操作。

• 使用 Azure Monitor 警报 API 收集历史警报，将其纳入冷存储中以进行高级分析。

• 对于无法通过自动响应解决的关键故障场景，请确保“Runbook 自动化”已就位，以便在提供手动解释和操作准备就绪后，能够快速且一致地执行应对措施。 使用警报通知快速识别需要手动解释的问题

• 在工程开发冲刺中预留空间，以推进报警功能的逐步改进，确保尚未考虑的新故障情景可以被最新的自动化措施充分涵盖。

• 在 CI/CD 流程中执行作准备测试，以验证部署更新的关键警报规则。

预测操作和AI 运维（AIOps）

机器学习模型可以应用于关联和排序操作数据，帮助筛选和分析过多警报的噪音，并在它们造成影响之前预测问题，从而加速紧急响应。

更具体地说，AIOps 方法可以应用于有关系统、用户和 DevOps 流程行为的关键见解。 这些见解可能包括识别现在发生的问题（检测）、量化问题发生的原因（诊断），或指示将来会发生什么（预测）。 此类见解可用于推动调整和优化应用程序以缓解活动或潜在问题（使用关键业务指标、系统质量指标和 DevOps 生产力指标）根据业务影响确定优先级的作。 执行的动作本身可以通过反馈循环融入系统，从而进一步训练基础模型，推动更多效率的提升。

Azure 中有多个分析技术，例如 Azure Synapse 和 Azure Databricks，可用于为 AIOps 生成和训练分析模型。 因此，本部分将重点介绍如何在应用程序设计中定位这些技术，以适应 AIOps 并推动预测作，重点介绍 Azure Synapse，通过将 Azure 数据服务的最佳功能与强大的新功能结合在一起来减少摩擦。

AIOps 用于推动预测行动，关联和解释在长时间内观察到的复杂操作信号，以便在问题发生之前进行更好的应对和防止。

设计注意事项

• Azure Synapse Analytics 提供多个机器学习（ML）功能。

  • ML 模型可以在 Synapse Spark 池中训练和运行，其中包含 MLLib、SparkML 和 MMLSpark 等库，以及常用的开源库，如 Scikit Learn。
  • 可以使用常见的数据科学工具（如 PySpark/Python、Scala 或 .NET）训练 ML 模型。

• Synapse Analytics 通过 Azure Synapse Notebooks 与 Azure ML 集成，这样就可以使用 自动化 ML 在 Azure ML 工作区中训练 ML 模型。

• Synapse Analytics 还允许使用 Azure 认知服务 实现 ML 功能来解决各种域中的一般问题，例如 异常情况检测。 认知服务可用于 Azure Synapse、Azure Databricks，以及客户端应用程序中的 SDK 和 REST API。

• Azure Synapse 原生集成了 Azure 数据工厂 工具，用于在编排管道中提取、转换和加载（ETL）或摄取数据。

• Azure Synapse 允许外部数据集注册到 Azure Blob 存储或 Azure Data Lake Storage 中存储的数据。

  • 可以在 Synapse Spark 池数据分析任务中使用已注册的数据集。

• Azure Databricks 可以集成到 Azure Synapse Analytics 管道中，以获取其他 Spark 功能。

  • Synapse 协调读取数据并将其发送到 Databricks 群集，可在其中对其进行转换和准备，以便进行 ML 模型训练。

• 源数据通常需要为分析和 ML 做好准备。

  • Synapse 提供各种工具来帮助准备数据，包括 Apache Spark、Synapse Notebook 和具有 T-SQL 和内置可视化效果的无服务器 SQL 池。

• 已训练、运营化和部署的 ML 模型可用于 Synapse 中的 批量 评分。

  • AIOps 方案（如在 CI/CD 管道中运行回归或降级预测）可能需要 实时评分。

• Azure Synapse 的订阅限制应在 AIOps 方法的上下文中完全理解。

• 若要完全整合 AIOps，必须持续将准实时可观测性数据馈送到实时 ML 推理模型中。

  • 应在可观测性数据流中评估异常情况检测等功能。

设计建议

• 确保所有 Azure 资源和应用程序组件都经过完全检测，以便完整的作数据集可用于 AIOps 模型训练。

• 将 Log Analytics 的操作数据从全球和区域的 Azure 存储帐户引入 Azure Synapse 进行分析。

• 使用 Azure Monitor 警报 API 检索历史警报并将其存储在冷存储中，以便操作数据以后用于 ML 模型中。 如果使用 Log Analytics 数据导出，请将历史警报数据存储在导出的 Log Analytics 数据所在的同一 Azure 存储帐户中。

• 为 ML 训练准备引入数据后，将其写回 Azure 存储，以便可用于 ML 模型训练，而无需运行 Synapse 数据准备计算资源。

• 确保机器学习模型的运作支持批处理和实时评分。

• 创建 AIOps 模型时，实现 MLOps 并应用 DevOps 实践，以 自动执行 ML 生命周期 ，以便训练、作化、评分和持续改进。 为 AIOps ML 模型创建迭代 CI/CD 过程。

• 评估 Azure 认知服务 的特定预测方案，因为其管理开销和集成开销较低。 请考虑 异常检测 ，快速标记可观测性数据流中的意外差异。

后续步骤

查看部署和测试注意事项。