你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
工作负载的运行状况建模
云应用程序生成大量操作数据，这使得快速查明和解决问题具有挑战性。 此挑战的一个常见原因是缺少根据工作负荷的功能自定义的运行状况基线，并且无法检测偏离该基线。
运行状况建模是一项可观测性练习，它将业务上下文与原始监视数据相结合，以量化工作负荷的总体运行状况。 它有助于设置可监视工作负荷的基线。 应考虑基础结构和应用程序组件中的遥测数据等数据。 运行状况建模还可能包含实现工作负荷质量目标所需的其他信息。
性能问题或操作降级可能会导致预期操作状态偏差。 通过对工作负荷的运行状况进行建模，可以识别偏差，并做出考虑业务影响的明智操作决策。
健康建模弥合了部落操作知识和可操作见解之间的差距。 它可帮助你有效地管理关键问题。 该概念对于最大限度地提高可靠性和运营效率至关重要。
本指南提供有关运行状况建模的实用指南，包括如何生成评估工作负荷及其所有子系统的运行时运行状况的模型。
| 术语 | 定义 |
|---|---|
| 运行状况建模 | 使用业务上下文将监视数据解释为运行状况状态的可观测性练习。 |
| 运行状况模型 | 逻辑实体及其给定作用域关系的图形表示形式。 每个节点都有一个运行状况状态定义，用于合理化整个模型的监视数据。 |
| 运行状况实体 | 一个逻辑组件，表示系统的各个单元、多个相关实体的逻辑组合或整个系统。 |
| 运行状况 | 定义且可衡量的状态，提供有关实体运行状况的有意义的操作见解。 |
| 运行状况信号 | 提供实体操作行为的见解的单个数据流。 |
| 模型模型 | 聚合建模范围，其中实体表示组件系统的不同运行状况模型。 |
建议观看此视频，以便大致了解运行状况建模。
什么是运行状况、运行状况建模和运行状况模型？
术语 运行状况 是指实体及其依赖项的操作状态。 该实体可以是系统的单个单元、多个相关实体的逻辑组合或整个系统。
建议以以下三种状态之一表示运行状况：
正常：以最佳方式运行并满足质量预期
降级：显示的行为不正常，这表示潜在问题
不正常：处于关键状态，需要立即注意
注意
可以使用分数而不是状态来表示运行状况，以提供更多的数据粒度。
通过将监视数据与域信息相结合来派生运行状况。 必须定义每个状态，并且必须可度量。 运行状况状态是使用 运行状况信号来计算的，这些信号是提供实体操作行为的见解的单个数据流。 信号可以包括指标、日志、跟踪或其他质量特征。 例如，虚拟机（VM）实体的运行状况信号可能会跟踪 CPU 使用率指标。 此实体的其他信号可能包括内存使用情况、网络延迟或错误率。
定义运行状况信号时，考虑工作负荷的非功能要求。 在 CPU 使用率示例中，包括每个运行状况状态的预期阈值。 如果利用率根据工作负荷要求超出允许的阈值，则系统将从“正常”过渡到“已降级”或“不正常”。 这些状态更改会触发相应的警报或操作。
运行状况建模要求实体具有从多个运行状况信号派生并针对工作负荷进行上下文化的明确状态。 例如，VM 的运行状况定义可能是：
正常：完全满足关键非功能要求和目标，例如响应时间、资源利用率和整体系统性能。 例如，95% 的请求在 500 毫秒内进行处理。 工作负荷以最佳方式使用 CPU、内存和存储等 VM 资源，并在工作负荷需求和可用容量之间保持平衡。 用户体验在预期级别。
已降级：资源未以最佳方式执行，但仍可正常运行。 例如，存储磁盘遇到限制问题。 用户可能会遇到响应缓慢。
不正常：降级超出了容忍的限制。 资源不再响应或可用，并且系统不再满足可接受的性能级别。 用户体验受到严重影响。
运行状况建模的结果是 逻辑实体及其工作负荷体系结构关系的模型 或图形表示形式。 每个节点都有一个运行状况状态定义。
重要
运行状况建模 是一个抽象的概念，如果你对业务方案有很好的了解，则可以在不同的范围内实现和应用。
在图像中：
实体 是表示系统方面工作负载的逻辑组件。 它们可以是基础结构组件，例如服务器、数据库和网络。 它们也可以是特定的应用程序模块、Pod、服务或微服务。 或者，实体可以捕获工作负荷中的用户交互和系统流。
注意
用户和系统流汇总了涉及应用程序和基础结构组件的业务方案中的非功能要求。 此摘要反映应用程序的业务价值。
实体之间的关系镜像系统中的依赖项链。 例如，应用程序模块可能会调用构成 关系的特定基础结构组件。
假设电子商务工作负载在Azure 服务总线队列上遇到失败消息激增的情况，导致付款失败。 由于隐含的收入损失，此问题对于组织至关重要。 尽管应用程序开发人员可能了解此指标对付款的影响，但这种部落知识通常不会在整个运营团队中共享。
运行状况模型可让操作员立即了解问题及其效果。 付款流取决于服务总线，这是工作负荷组件之一。 视觉表示形式显示服务总线实例的降级状态及其对付款流的影响。 操作员可以了解问题的重要性，并将修正工作重点放在该特定组件上。
运行状况建模在上述方案中非常重要，方法如下：
它通过启用更快的问题隔离来改进检测（TTD）和缓解时间（TTM），从而更快地检测问题和潜在修复。
操作员根据运行状况收到警报，从而减少了不必要的噪音。 运营商收到了有关业务对付款影响的特定上下文的通知。
依赖项链帮助操作员充分了解操作问题的程度。 此知识加速了影响评估，并导致优先响应。 运算符还可以轻松识别级联或关联问题。
操作员以准确性进行了事件后活动，因为运行状况模型提供了对异常的根本原因和涉及的特定运行状况信号的见解。
它使监视数据对所有团队成员都有意义。 它弥合了部落知识与分享见解之间的差距。
组织使用运行状况模型作为未来 AI 驱动运营投资的基线来获取智能见解。
运行状况模型架构
运行状况模型提供针对可观测性用例进行优化的不同数据架构。 此架构将运行状况建模从抽象概念转换为可衡量的解决方案。 通过对特定要求、目标和体系结构上下文进行建模，你可以根据独特的方案定制运行状况数据。
运行状况是一个相对数据概念。 每个模型表示其上下文范围唯一且优先的运行状况数据，即使它使用相同的实体集也是如此。 在特定方案中构成 正常 的情况在其他上下文中可能有很大的不同。
例如，考虑工作负荷中具有相同类型的 Azure 资源。
- VM A 运行 CPU 敏感型应用程序。
- VM B 处理内存密集型服务。
这些计算机的运行状况定义不同。 CPU 使用率指标可能会影响 VM A 的运行状况，VM B 可能会确定与内存相关的指标的优先级。
重要
运行状况模型不应将所有失败都视为相同。 它应清楚地区分预期故障或暂时性故障和真正的灾难状态。
生成运行状况模型
构建运行状况模型的第一步是逻辑设计练习，这通常涉及以下部分中介绍的活动。
评估工作负荷设计
通过评估工作负荷设计的以下组件来开始此逻辑设计练习。
计算群集和数据库等基础结构组件
在计算上运行的应用程序组件及其相关组件
组件之间的逻辑或物理依赖关系
例如，电子商务应用程序的运行状况模型应表示用户登录、结帐和付款等关键进程的当前状态。
使用业务要求进行上下文化
评估每个流对组织的相对重要性和整体影响。 考虑用户体验、安全性和运营效率等因素。 例如，在大多数情况下，付款流程的失败可能比报告过程失败更重要。
确定处理与每个流相关的问题的升级路径。 有关详细信息，请参阅 使用流优化工作负荷设计。
注意
仅当合并业务方案和上下文时，才能实现运行状况建模的价值。 然后，你可以从运营问题中合理化业务影响。
映射到可靠性指标
在整个应用程序设计中查找相关的 可靠性指标 。
请考虑为整个应用程序及其单个业务流程定义服务级别指标（SLI）和服务级别目标。 这些 SLI 和 SLO 应与为运行状况模型考虑的特定运行状况信号保持一致。 为此，可以创建一个全面的运行状况定义，以准确反映应用程序的可接受的服务级别的成就。
重要
SLI 和 SLO 是关键运行状况信号。 它们创建一个有意义的运行状况定义，反映所需的服务级别以及其他质量属性。 还可以定义服务运行状况目标（SHO），以捕获要在聚合时间范围内实现的运行状况。
识别运行状况信号
若要构建全面的运行状况模型，请关联各种类型的监视数据，包括指标、日志和跟踪。 这样做可确保运行状况概念准确地反映特定实体或整个工作负荷的运行时状态。
使用平台指标和日志
在运行状况建模的上下文中，必须从基础 Azure 资源收集平台级指标和日志。 这些指标包括 CPU 百分比、网络进出网络以及每秒磁盘操作。 可以在运行状况模型中使用此数据来检测和预测潜在问题，同时维护可靠的环境。
此外，此方法可帮助你区分暂时性故障或临时中断，以及非过渡性故障或永久性问题。
注意
最佳做法是将所有应用程序资源配置为将诊断日志和指标定向到所选日志聚合技术。 使用 Azure Policy 生成防护措施，以确保整个应用程序的诊断设置一致，并为每个 Azure 服务强制实施所选配置。
添加应用程序日志
应用程序日志是运行状况模型诊断数据的重要源。 下面是应用程序日志记录的一些最佳做法：
使用语义或结构化日志记录。 结构化日志有助于大规模自动消耗和分析日志数据。
请考虑在 Azure Monitor 日志工作区而不是存储帐户中存储 Azure 资源指标和诊断数据。 通过使用此方法，可以使用 Kusto 查询创建运行状况信号，以便进行高效的评估。
在生产环境中记录数据。 在应用程序在生产环境中运行时捕获全面的数据。 足够的信息对于运行状况评估和诊断任何检测到的生产问题至关重要。
记录服务边界处的事件。 包含遍历服务边界的相关 ID。 如果事务涉及多个服务，其中一个服务失败，则相关 ID 可帮助跟踪整个应用程序的请求并查明失败原因。
使用异步日志记录。 避免可能会阻止应用程序代码的同步日志记录操作。 异步日志记录通过在日志写入期间阻止请求积压来确保可用性。
将应用程序日志记录与审核分开。 独立于诊断日志维护审核日志。 尽管审核记录符合合规性或法规要求，但保留这些记录会阻止丢弃的事务。
实现分布式跟踪
通过将 遥测 数据关联到关键系统流来实现分布式跟踪。 相关遥测提供端到端事务的见解，对于发生故障时有效的根本原因分析（RCA）至关重要。
使用运行状况探测
在应用程序外部实现并运行运行状况探测，以显式检查应用程序的运行状况和响应能力。 使用探测响应作为运行状况模型中的信号。
可以通过测量整个应用程序或其各个组件的响应时间来实现运行状况探测。 探测可以运行进程来测量延迟和检查可用性，或从应用程序中提取信息。 有关详细信息，请参阅 运行状况终结点监视模式。
大多数负载均衡器都支持运行运行状况探测，这些探测按配置的间隔 ping 应用程序终结点。 或者，可以使用外部监视器服务。 监视器服务从工作负荷中的多个组件聚合运行状况检查。 监视程序还可以托管代码，这些代码可立即针对已知运行状况进行修正。
采用结构和功能监视技术
结构监视涉及为应用程序配备语义日志和指标。 应用程序直接收集这些指标，其中包括当前内存消耗、请求延迟和其他相关的应用程序级数据。
使用功能监视加强监视过程。 此方法侧重于衡量平台服务及其对整体用户体验的影响。 与结构监视不同，功能监视不需要系统的详细知识。 它测试应用程序的外部可见行为。 此方法可用于评估 SLO 和 SLI。
为设计建模
将标识的应用程序设计表示为实体和关系。 将运行状况信号映射到特定组件，以量化实体级别的运行状况状态。 考虑组件的关键性，以确定运行状况状态应如何通过模型传播。 例如，报告组件可能不像其他组件那样重要，这会导致对整体工作负荷运行状况产生不同影响。
设置可操作警报
使用评估的运行状况状态触发警报和自动操作。 运行状况应作为核心可观测性数据原则集成到现有操作 Runbook 中。
通常，监视数据和警报规则之间存在一对一映射，这可能会导致不良结果，例如警报风暴和环境警报噪音。 例如，在计算群集中，大量基于 CPU 利用率和错误计数的 VM 级别警报可能会使操作员在故障期间不知所措，并导致解决延迟。 同样，当存在大量配置的警报时，环境警报噪音通常会导致被忽略或忽略的警报。
运行状况模型引入了监视数据和警报规则之间的分离。 运行状况定义将许多信号聚合为单个运行状况状态，这会减少警报数，以便操作员可以专注于对组织至关重要的高价值警报。 请考虑电子商务方案。 可以设置警报，以发送有关流程付款流运行状况更改的通知，而不是服务总线队列等基础资源中的更改。
注意
跨运行状况模型的所有层发出警报的功能为不同的工作负荷角色提供了灵活性。 应用程序所有者和产品经理可以向关键业务方案或整个工作负荷中的运行状况状态更改发出警报。 操作员可以根据基础结构或应用程序组件的运行状况发出警报。
可视化模型
创建可视化表示形式（如表或图形），以有效传达运行状况模型的当前状态和历史记录。 确保可视化效果与业务上下文保持一致，并提供可操作的见解。
可视化运行状况模型时，请考虑采用 交通灯 方法，使运行状况状态立即跨依赖项链有见解。
为正常分配绿色，为降级分配琥珀色，为不正常分配红色。 通过快速识别颜色编码状态，可以有效地找到任何应用程序降级的根本原因。
注意
我们建议你在为健康模型创建仪表板时考虑有视力障碍的人的辅助功能要求。 有关关系图最佳做法，请参阅 体系结构设计图。
采用运行状况模型
生成运行状况模型后，请考虑以下用例来驱动故障或操作问题的检测和解释。
各种角色的适用性
运行状况建模可以提供特定于作业功能的信息或工作负荷的同一上下文中的角色。 例如，DevOps 角色可能需要操作运行状况信息。 安全官员可能更关心入侵信号和安全暴露。 数据库管理员可能仅对数据库资源的应用程序模型的子集感兴趣。
为不同的利益干系人定制健康见解。 请考虑从重叠数据集创建单独的模型。
持续验证
使用运行状况模型优化测试和验证过程，例如负载测试和混乱测试。 可以在测试期间验证运行时操作状态，并通过将运行状况模型合并到工程生命周期中来评估模型在规模和故障方案中的有效性。
组织运行状况
尽管运行状况建模通常与量化各个应用程序的运行状况状态相关联，但其适用性超出了该范围。
在单个工作负荷级别，运行状况模型为应用程序可观测性和操作见解提供了基础。 每个应用程序可以有自己的运行状况模型，用于捕获其上下文中每个运行状况状态的含义。
可以通过构建 模型模型将多个运行状况模型合并为高级构造。 例如，可以使用运行状况模型作为较大模型中的组件来构建业务部门或整个云资产的可观测性足迹。 运行状况模型将资产中的工作负荷表示为顶级图中的节点。 使用此模型中的关系捕获应用程序间依赖项，包括数据流、服务交互和共享基础结构。
请考虑拥有各种电子商务、付款和订单处理的零售公司。 可以将其中每个应用程序定义为独立的运行状况模型，以量化该工作负荷的运行状况含义。 然后，可以使用父模型将所有组件运行状况模型映射为实体，并通过依赖项链捕获应用程序间操作影响。 例如，如果电子商务应用程序变得不正常，则会对支付应用程序产生级联影响。
适用于 IT 操作的运行状况趋势和 AI
运行状况建模提供经过优化的特定业务上下文的限定操作基线。 AI for IT 运营（AIOps）是提高运营效率的热门方法。 运行状况数据是机器学习模型分析运行状况趋势的基础输入。 例如，机器学习模型可以：
从状态更改和推荐操作中提取更多见解。
分析一段时间内的运行状况趋势，以推动问题预测和模型优化。
维护运行状况模型
维护热度模型是一项持续工程活动，与应用程序的开发和操作保持一致。 随着应用程序的发展，请确保运行状况模型并行发展。
此外，请像应集成到开发生命周期中的工作负荷项目一样处理运行状况模型。 采用基础结构即代码 （IaC），以便对运行状况模型进行一致的版本控制管理。 使用自动化使模型在添加或删除工作负载中的基础结构和应用程序组件时保持最新状态。
随着时间推移，运行状况数据的价值逐渐减少。 若要优化运营效率并降低成本，请避免将运行状况数据保留超过 30 天。 如有必要，可以存档数据以满足审核要求，或者在 AI 中将长期模式分析用于 IT 操作的方案中。
注意
存档运行状况数据时，请确保将其与模型的配置状态结合使用。 在没有此上下文的情况下，解释状态更改可能很困难。
相关链接
- 若要在 ASP.NET 中实现运行状况探测，请参阅 ASP.NET Core 中的运行状况检查。
- 要了解监视指标，请参阅《Azure Monitor 指标概述》。
- 有关使用 Application Insights 的信息，请参阅 Application Insights。
- 有关与任务关键型工作负荷相关的设计注意事项和建议，请参阅 Azure 上任务关键型工作负荷的运行状况建模和可观测性。
- 有关实践体验，请参阅 设计任务关键型工作负荷的运行状况模型。