Azure Monitor 健康模型概念（预览版）

本文介绍创建和使用 Azure 运行状况模型必须了解的概念。 这包括构成模型的组件、这些组件的相关方式以及确定每个组件的运行状况。 有关创建和配置这些组件的详细信息 ，请参阅 Azure Monitor 中的设计器 。

实体

实体是构建Azure Monitor 运行状况模型的基块。 它们表示工作负载的不同组件和任何支持业务流程。 从模型链接到的服务组中发现运行状况模型中的实体。 本文介绍不同类型的实体、它们彼此之间的关系以及如何在不同的视图中配置它们。

如以下各节中所述，有三种不同的实体类型。

根实体

所有运行状况模型都有一个名为 根实体 的实体，该实体表示模型本身。 运行状况模型中的所有其他实体都应直接或通过其他关系连接到根。 无法删除根实体。

根实体的主要用途是表示支持运行状况模型的服务组所表示的工作负荷或应用程序的总体运行状况。 可以跟踪应用程序随时间推移的运行状况，并根据根实体的运行状况创建警报，该实体可以作为模型中各个实体的补充或替代。

Azure 资源实体

Azure 资源实体表示当前订阅或可以访问的订阅中的 Azure 资源。 如果实体位于你有权访问的共享服务组中，则实体也可能驻留在另一个订阅中。

若要将 Azure 资源实体添加到你的运行状况模型，首先需要将其作为成员添加到你的服务组。 然后，运行状况模型将发现资源，并自动将 Azure 资源实体添加到模型，以表示此新的服务组成员。 此检测每 5 分钟自动运行一次。

运行状况模型包括 Azure 资源的表示形式，而不是资源本身。 资源可以在多个运行状况模型中表示，每个资源都可以定义不同的监视要求和业务逻辑。 如果资源由不同模型中的多个实体表示，则会单独评估每个实体的信号，并且每个实体都有其独立的运行状况状态。

从与资源关联的指标或日志评估应用于每个 Azure 资源实体的信号。 此数据的集合是为资源本身定义的，而不是在运行状况模型中定义。 相反，运行状况模型侧重于如何根据工作负荷中资源角色的上下文解释该数据。

泛型实体

泛型实体表示不是 Azure 资源的应用程序或工作负荷的一部分。 它可以表示工作流中的一些手动过程，也可以使用它来表示其他实体（例如区域或业务部门）的一些聚合。 泛型实体可以有自己的信号，尽管它可能只有其子实体的运行状况确定的运行状况状态。 与从服务组自动发现的 Azure 资源实体不同，需要手动将运行状况组件添加到模型。

关系

关系表示一个实体在另一个实体上的依赖关系，或者它可能表示将多个实体聚合到单个实体中。 一个实体可以有多个子实体和多个父实体。 关系的主要功能是支持运行状况传播，如 运行状况状态中所述。

在大多数运行状况模型中，所有实体将直接或间接连接到根实体。 这样，就可以将模型中所有实体的运行状况汇总到根实体。 这对于跟踪工作负荷的总体运行状况以及针对整个工作负荷的运行状况发出警报非常有用。

信号

Azure Monitor 运行状况模型中实体的 运行状况状态 由一个或多个 信号决定。 信号是指标或查询中的一个值，该指标或查询会定期与与该实体的每个运行状况状态关联的阈值进行比较。

运行状况模型不执行信号所依赖的数据收集，而是对模型中包含的 Azure 资源收集的数据采样或查询。 必须使用 Azure Monitor 的其他功能配置此数据收集。 由于会自动为所有资源收集 平台指标 ，因此 Azure 资源信号的数据将始终可用。 有关启用数据收集以支持 Log Analytics 工作区和 Azure Monitor 工作区信号的信息，请参阅 Azure Monitor 的监视数据源。

健康状况

实体的 运行状况状态 表示其执行所需任务的能力。 它可以在预期的范围内完全正常运行并执行，或者它可能具有有限的功能或性能下降，或者它根本无法正常运行。 运行状况由与实体关联的 信号 确定，它可能受任何子实体的运行状况状态的影响。 除了跟踪模型随时间推移的运行状况之外，还可以查看工作流及其组件的最新运行状况。

Azure Monitor 运行状况模型使用下表中的运行状况来表示模型中每个实体的运行状况。 明确确定各个运行状况状态的阈值的定义并不存在，但您需要根据特定工作负荷和业务的要求来指定每个阈值。

图标	国家	DESCRIPTION
	正常	该实体按预期工作。
	已降级	实体正在工作，但功能或性能下降。 不计入运行状况目标的故障时间。
	不健康	该实体无法正常工作或性能无法接受。 计入运行状况目标的故障时间。
	未知	由于数据不足或信号不足，无法确定实体的运行状况。

以下示例演示了具有多个指标信号的 Azure 资源实体。 每项对于已降级和运行不正常状态都有一个定义的范围。 当每个信号的值超出已降级阈值时，实体的运行状况状态为正常，以匹配其所有信号。 当信号的值处于降级或不正常的阈值内时，该信号将设置为相应的运行状况状态，并将实体设置为其所有信号 的最差状态 。

在以下示例中，实体设置为降级状态，因为其中一个信号处于降级状态，另外两个状态正常。 如果任何信号不正常，则实体将设置为不正常状态。

运行状况传播

除了其自身的信号外，实体的运行状况状态还受其子实体的影响。 这通常表示运行状况模型中一个实体在另一个实体上的依赖关系。 虽然父级的信号可能正常，但可以假定它无法完全运行，因为依赖于它的另一个实体无法正常工作。

还可以使用运行状况汇总来合并多个实体的运行状况。 例如，你可能想要跟踪应用程序的特定组件的运行状况，或特定区域或业务部门中的资源。 在这种情况下，可以将 泛型实体 添加到模型中，以汇总要聚合的子实体的运行状况。

以下示例演示了示例运行状况模型中的运行状况传播。 事件中心实体和表示处理传入消息的应用程序组件的泛型实体显示信号。 即使消息处理器的信号正常，但其实体运行状况状态仍不正常，因为它依赖的事件中心状态不正常。 此不正常状态将传播到根实体，因为它是连接到根实体的最差状态。

影响

实体 的影响 决定了其运行状况如何传播到其父级（s）。 下表描述了不同的影响设置。 选择 实体编辑器中每个实体的设置。

以下示例显示了每个冲击设置的效果。 每个子实体处于不正常状态，但父运行状况状态因每个子级的影响设置而异。

健康目标

实体的健康目标是该实体应保持健康状态的目标时间百分比。 这样就可以跟踪一段时间内可用性目标的成就。 健康目标是一个可选值。 可以选择仅为根实体设置一个运行状况目标，而不是为运行状况模型中的每个实体设置一个运行状况目标，该目标表示整个工作负荷的运行状况目标。 选择 实体编辑器中每个实体的设置。

下面是显示运行状况目标报告的示例实体的实体详细信息中的历史记录。

警报

Azure Monitor 运行状况模型中的警报允许在实体运行状况发生更改时主动通知。 这些警报与 Azure Monitor 警报 集成，可以使用相同的 作组 来通知团队或采取纠正措施。

健康模型中的警报与 Azure Monitor 中的其他警报显著不同，这些警报通常针对与资源关联的每个信号发出警报，而无需考虑该资源在应用程序或工作负荷中的角色上下文。 运行状况模型允许你创建对业务更有意义的警报，并减少针对相同数量问题生成的警报总数。

下表总结了 Azure 资源的警报规则与运行状况模型中实体的警报规则之间的差异。

你可能已经为运行状况模型中的实体所表示的 Azure 资源定义了警报规则。 这些警报规则将继续生成警报，因此，如果为实体的运行状况创建警报规则，可能需要禁用警报规则。

运行状况模型中的警报规则还提供了为不同受众创建不同警报的机会。 在以下示例中，为 Azure 资源实体创建向应用程序团队发送电子邮件的警报规则，因为这是诊断问题并采取纠正措施的团队。 向区域业务团队发送电子邮件的警报规则是为通用实体创建的，因为这是将向客户传达问题的团队，并就业务影响做出决策。 最后，将创建根实体上的警报规则，以便向执行团队发送电子邮件，以了解应用程序不可用。

后续步骤

• 创建新的健康模型。
• 使用设计器配置健康模型。