通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

  • 项目

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

大多数任务关键型应用程序在规模和复杂性方面都非常重要，因此会生成大量的操作数据，这使得评估和确定最佳操作操作变得困难。 运行状况建模最终致力于通过将原始监视日志和指标与关键业务要求一起扩充，以量化应用程序运行状况，从而推动运行状况状态的自动评估，以实现一致且快速的操作，从而最大程度地提高可观测性。

此设计领域侧重于定义可靠的运行状况模型的过程，通过可观测性和操作构造映射量化的应用程序运行状况状态，以实现操作成熟度。

重要

本文是 Azure Well-Architected 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从 什么是任务关键型工作负载开始？

在努力实现可靠性最大化时，运营成熟度有三main级别。

  1. 在出现问题时对其进行检测和响应。
  2. 诊断 正在发生或已发生的问题。
  3. 在 问题发生之前预测和预防问题。

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

分层应用程序运行状况

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

重要

定义“不正常”状态时，表示应用程序的所有级别。 必须区分暂时性和非暂时性故障状态，以限定相对于不可用的服务降级。

设计注意事项

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

  • 运行状况模型完全依赖于它所表示的解决方案的上下文，因此无法“开箱即用”解决，因为“一种大小不适合所有大小”。

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

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

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

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

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

设计建议

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

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

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

    • 用户流的运行状况分数应以所有映射组件的最低分数表示，并考虑用户流的非功能性要求的相对实现。
    • 用于计算运行状况分数的模型必须一致地反映操作运行状况，否则，应调整和重新部署模型以反映新的知识。
    • 定义运行状况分数阈值以反映运行状况。

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

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

  • 使用运行状况模型计算可用性服务级别目标 (SLO) 实现，而不是原始可用性，确保服务降级与不可用之间的分界线反映为单独的 SLO。

  • 在 CI/CD 管道和测试周期中使用运行状况模型来验证代码和配置更新后应用程序运行状况是否得到维护。

    • 运行状况模型应用于在 CI/CD 过程中进行负载测试和混沌测试期间观察和验证运行状况。

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

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

示例 - 分层运行状况模型

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

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

任务关键示例运行状况定义

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

// 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 资源都会公开日志和指标，但必须适当配置资源，以便将诊断数据路由到所需的数据接收器。

提示

Azure 提供各种 内置策略 ，可以应用这些策略，以确保已部署的资源配置为将日志和指标发送到 Log Analytics 工作区。

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

  • 不同的操作数据类型可能需要不同的保留期。 例如，安全日志可能需要长期保留，而性能数据不太可能需要在 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 日志具有 用户查询限制限制，这些限制可能显示为对客户端（例如可观测性仪表板）的可用性降低。

    • 每个用户有五个并发查询：如果已有五个查询正在运行，则会在每用户并发队列中放置其他查询，直到运行查询结束。
    • 并发队列中的时间：如果查询在并发队列中处于三分钟以上，则会终止该查询，并返回 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）都根据引入的数据量和保留数据的持续时间 收费 。

    • 如果启用了 Sentinel，则引入到 Log Analytics 工作区的数据可以免费保留，最多可以保留 31 天 (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 和高级分析优化基础运行状况模型并通知预测操作。

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

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

  • 为 Log Analytics 中的操作数据类型选择适当的保留期，在存在“热”可观测性要求的工作区中配置更长的保留期。

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

注意

部署到 Azure 登陆区域时，如果需要集中存储操作数据，可以在实例化时 对数据进行分支 ，以便将数据引入到专用于应用程序的集中式工具和 Log Analytics 工作区中。 或者，公开对应用程序 Log Analytics 工作区的访问权限，以便中心团队可以查询应用程序数据。 最终，源自解决方案的操作数据在专用于应用程序的 Log Analytics 工作区中可用至关重要。

如果需要 SIEM 集成，请不要发送原始日志条目，而是发送关键警报。

  • 仅当需要优化性能时，才在 Application Insights 中配置采样，或者如果不进行采样，则成本高昂。

    • 过多的采样可能会导致操作信号丢失或不准确。

  • 将相关 ID 用于所有跟踪事件和日志消息，从而让其与给定请求关联。

    • 为所有调用返回相关 ID，而不仅仅是失败的请求。

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

    • 应用程序代码应使用 Application Insights 来简化 分布式跟踪，方法是在发生故障时向调用方提供包含相关 ID 的综合错误消息。

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

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

    • 使用 AKS 时，请为 pod) (每个部署配置运行状况终结点，以便 Kubernetes 可以正确确定 Pod 是正常还是运行不正常。
    • 使用Azure 应用服务时，请配置运行状况检查，以便向尚未就绪的实例发送流量并确保快速回收不正常的实例，使横向扩展操作不会导致错误。

如果应用程序订阅了 Microsoft Mission-Critical 支持，请考虑向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 登陆区域，请考虑查询 中心平台 Log Analytics 工作区 ，如果平台资源（例如用于本地通信的 ExpressRoute）存在关键依赖项。

  • 应使用“红绿灯”模型直观地表示“正常”和“不正常”状态，绿色用于说明何时完全满足关键非功能性需求以及优化利用资源。 使用“绿色”、“琥珀色”和“红色”表示“正常”、“已降级”和“不可用”状态。

  • 使用 Azure 仪表板为全局资源和区域部署标记创建操作镜头，表示关键指标，例如 Azure Front Door 的请求计数、Azure Cosmos DB 的服务器端延迟、事件中心的传入/传出消息以及 AKS 的 CPU 使用率或部署状态。 仪表板应专门针对提高操作有效性进行定制，注入从失败场景中获得的经验，确保 DevOps 团队可直接查看关键指标。

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

  • 部署自承载 Grafana 时，请采用高度可用的异地分布式设计，确保关键操作仪表板能够针对区域性平台故障和级联错误情况进行复原。

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

      • 跨部署区域配置数据库复制。

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

      • 跨考虑的部署区域部署App 服务实例。

      应用服务提供低摩擦容器平台，非常适合低规模方案（如操作仪表板），将 Grafana 与 AKS 隔离，可明确区分主要应用程序平台和该平台的操作表示形式。 有关进一步的配置建议，请参阅应用程序平台设计区域。

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

    • 将应用服务和数据库读取副本 (replica) 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 流程中执行操作就绪性测试，以验证部署更新的关键警报规则。

AIOps) (预测操作和 AI 操作

可以应用机器学习模型来关联操作数据并设置其优先级，帮助收集与筛选过多警报“噪音”和在问题造成影响之前预测问题相关的关键见解，以及在问题造成影响时加速事件响应。

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

任务关键型 AIOps 方法

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

AIOps 用于驱动预测操作，解释和关联在持续期间观察到的复杂操作信号，以便在问题发生之前更好地响应和预防问题。

设计注意事项

  • Azure Synapse Analytics 提供多种机器学习 (ML) 功能。

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

  • Synapse Analytics 通过 Azure Synapse Notebook 与 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 数据准备计算资源。

  • 确保 ML 模型操作化支持批量评分和实时评分。

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

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

后续步骤

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

部署和测试