Project Flash - 使用 Azure 资源运行状况监视 Azure 虚拟机可用性

Azure 资源运行状况是 Flash 提供的一种解决方案。 Flash 是专用于生成稳固、可靠且快速机制的项目的内部名称，可供客户监视虚拟机 (VM) 运行状况。

本文介绍了如何使用 Azure 资源运行状况监视 Azure 虚拟机可用性。 有关 Flash 解决方案的一般概述，请参阅 Flash 概述。

有关 Flash 提供的其他解决方案的特定文档，请从以下文章中选择：

• 使用 Azure Monitor 监视 Azure 虚拟机可用性

Azure 资源运行状况

它通过门户为各个资源提供即时的且用户友好的运行状况检查。 客户可以快速访问门户上的资源运行状况边栏选项卡，还可以查看 30 天的运行状况检查历史记录，这使其成为一个可以快速且直接地进行故障排除的出色工具。 现有的 Azure 资源运行状况功能有助于你诊断影响 Azure 资源的服务问题并获得相应的支持。 它会报告资源当前的和过去的运行状况，显示每个资源都不可用的任何时间范围。

但我们知道，我们的客户和合作伙伴有兴趣了解导致潜在技术问题的原因，并改善他们接收有关问题的通信的方式，以将其纳入监视流程，向其他利益干系人解释问题，并最终为业务决策提供信息。

Azure 资源运行状况中出现的 VM 问题的根本原因

我们最近对资源运行状况体验进行了改进，这将增强我们与客户共享的有关 VM 故障的信息，并提供有关导致问题的根本原因的进一步背景信息。 现在，除了在 VM 的可用性受到影响时获得快速通知之外，客户可能还希望我们在稍后（此时我们的自动化根本原因分析 (RCA) 系统已识别出导致 VM 故障的 Azure 平台故障组件）添加根本原因。 让我们通过一个例子来看看这个过程在实践中是如何工作的：

在时间 T1，服务器机架由于网络问题而脱机，导致机架上的 VM 失去连接。 最近与网络体系结构相关的可靠性改进将在未来的提高可靠性博客文章中分享 - 请关注此空间！

在时间 T2，Azure 的内部监视发现它无法访问机架上的 VM，于是开始通过将受影响的 VM 重新部署到新机架来缓解影响。 在此期间，系统会向资源运行状况发送一条注释，通知客户其 VM 目前受到影响，因此不可用。

在时间 T3，来自机架顶部交换机、主机和内部监视系统的平台遥测数据在我们的 RCA 引擎中关联在一起，得出故障的根本原因。 计算完成后，RCA 将与相关的体系结构复原能力建议一起发布回资源运行状况。客户可以实施这些建议，以最大程度地减少未来产生影响的可能性。

虽然最初的停机通知功能已有几年历史，但发布根本原因声明是一项新增功能。 现在，让我们深入了解如何得出这些根本原因的细节。

根本原因分析引擎

让我们仔细看看前面的示例，并详细了解 RCA 引擎的工作原理及其背后的技术。 VM 的 RCA 引擎的核心是 Azure 数据资源管理器 (ADX)，这是一项针对大容量日志遥测分析进行优化的大数据服务。 使用 Azure 数据资源管理器，你能够轻松分析来自构成 Azure 平台的设备和服务的数 TB 日志遥测数据，将它们联接在一起，并解释相关的信息流，以得出不同故障场景的根本原因。 这最终是一个多步骤的数据工程过程：

阶段 1：检测故障时间

根本原因分析的第一阶段是定义在其下执行分析的触发器。 对于虚拟机，我们希望在 VM 意外重新启动时确定根本原因，因此触发器是 VM 从运行状态转换为关闭状态。 大多数情况下，从平台遥测数据中识别这些转换很简单，但在某些类型的基础结构故障（平台遥测数据可能由于设备故障或断电而丢失）中，此操作会变得较复杂。 若要处理这些类型的故障，你需要其他技术，例如跟踪数据丢失作为 VM 可用性转换的可能指示。 Azure 数据资源管理器在此时的序列分析方面表现出色。有关此过程的技术的更详细信息，可以访问 Microsoft 技术社区：在 Azure 数据资源管理器中使用窗口函数和时序函数计算故障时间。

阶段 2：相关性分析

一旦定义了触发器事件（在本例中，VM 转换为运行不正常状态），下一阶段就是相关性分析。 在此步骤中，我们使用存在的触发器事件来关联遥测数据，这些遥测数据来自 Azure 平台各处，例如：

• Azure 主机：托管 VM 的物理刀片机。
• TOR：机架顶部网络交换机。
• Azure 存储：托管 Azure 虚拟机的虚拟磁盘的服务。

每个此类系统都有自己的遥测源，需要对其进行分析并将其与 VM 停机触发器事件相关联。 此过程是这样完成的：先了解 VM 和可能导致 VM 故障的底层系统的依赖关系图，然后将所有这些依赖系统的运行状况遥测数据联接在一起，对 VM 转换那段时间发生的事件进行筛选。 Azure 数据资源管理器直观而强大的查询语言可以提供记录的模式（例如用于将临时遥测流关联在一起的时间窗口联接），从而提供帮助。 在此关联过程结束时，我们得到了一个数据集，该数据集表示 VM 故障时间转换，包含来自所有依赖系统的相关的平台遥测数据，这些依赖系统可能导致 VM 故障或可能具有用于确定导致 VM 故障的信息。

阶段 3：根本原因归因

此过程的下一步是归因。 将所有相关数据收集到一个数据集中以后，就可以应用归因规则来解释信息并将其转换为面向客户的根本原因陈述了。 如果回到最初的 TOR 故障示例，那么在经过相关性分析后，我们可能会得到许多需要解释的有趣信息。 例如，监视 Azure 主机的系统可能有相关日志，表明它们在此期间失去了与主机的连接。 我们还可能有与虚拟磁盘连接性问题相关的信号，以及来自 TOR 设备的有关故障的明确信号。 现在，所有这些信息都已扫描完毕，在作为根本原因时，明确的 TOR 故障信号优先于其他信号。 此优先级流程及其背后的规则由领域专家构建，会随着 Azure 平台的发展而进行修改。 机器学习和异常情况检测机制基于这些已归因的根本原因，有助于识别改进这些分类规则的机会，可检测这些故障的故障率的模式变化，从而将其反馈到安全部署管道。

阶段 4：RCA 发布

最后一步是将根本原因发布到 Azure 资源运行状况，客户可以在其中看到它们。 发布是通过一个简单的 Azure Functions 应用程序完成的，该应用程序定期查询 Azure 数据资源管理器中已处理的根本原因数据，并将结果发送到资源运行状况后端。 由于信息流可能会出现各种数据延迟，因此 RCA 偶尔会在此过程中进行更新，以反映已到达的更好的信息源，从而导致比最初发布的内容更具体的根本原因。

持续操作

识别任何问题的根本原因并向我们的客户和合作伙伴传达它只是一个开始。 我们的客户可能需要获取这些 RCA 并与其客户和同事分享。 我们希望在此工作的基础上更轻松地识别和跟踪资源 RCA，并轻松共享它们。为了实现这一目标，我们正在对后端进行更改，以生成独特的按资源和按故障时间分类的跟踪 ID。我们可以向你公开这些 ID，以便你可以轻松地将故障时间与其 RCA 相匹配。 我们还在开发新功能，以便更轻松地通过电子邮件发送 RCA，并最终为你的 VM 订阅 RCA。 使用此功能，你可以在发生不可用事件后直接在收件箱中注册 RCA，而无需采取进一步操作。

后续步骤

若要了解有关所提供解决方案的详细信息，请参阅相应的解决方案文章：

• 使用 Azure Monitor 监视 Azure 虚拟机可用性

有关如何监视 Azure 虚拟机的一般概述，请参阅监视 Azure 虚拟机和监视 Azure 虚拟机参考。