计划事件为应用程序准备虚拟机（VM）维护提供了时间。
计划事件会在虚拟机可用性发生任何中断之前提供，以便应用程序可以为此类事件做好准备并限制中断。 它适用于所有Azure 虚拟机类型，包括 Windows 和 Linux 上的 PaaS 和 IaaS。
本概述介绍如何在应用程序中使用计划事件来限制中断。 请参阅以下页面，了解有关可以从中使用计划事件的特定终结点的详细信息：
来自 IMDS 的预定事件（Windows）
来自 IMDS （Linux） 的计划事件
来自事件网格的计划事件
来自 "Azure Resource Graph" 的计划事件
请参阅“资源运行状况批注”，了解有关过去影响的根本原因分析和反应性通知的更多信息。
注释
事件网格中的计划事件和 Azure Resource Graph 目前处于预览状态。
有关 Beta 版本、预览版或尚未正式发布的 Azure 功能所适用的法律条款，请参阅预览版使用条款 | Microsoft Azure。
IMDS（Windows 和 Linux）中的计划事件已正式发布。
为何使用计划事件
在Azure上运行的 VM 偶尔会由于它们依赖的硬件或软件系统的不可避免维护而遇到中断。 计划事件在操作发生之前提供通知，以便应用程序可以执行提高其可用性、可靠性和可维护性的任务，包括：
检查点和还原。
连接清空。
主要副本故障转移。
从负载均衡器池中删除。
事件日志记录。
正常关闭。
使用计划事件，应用程序可以在维护发生时发现并触发任务来限制其影响。
计划事件在以下用例中生成：
平台启动的维护（例如，VM 重新启动、实时迁移或主机的内存保留更新）。
虚拟机正在降级的主机硬件上运行，预计不久会失败。
虚拟机在硬件故障的主机上运行。
用户启动的维护（例如，用户重启或重新部署 VM）。
现成 VM 和现成规模集实例逐出。
由于事件与所描述的操作之间的短时间，计划事件适用于自动化计算机到机器通信，而不是由人工操作员读取和操作。 对于有关过去事件的人工可读信息，请使用资源运行状况批注，并使用维护配置来获取有关最多提前 35 天计划的操作的人工可读信息。
了解和处理计划事件
计划事件提供有关 VM 中断的方式和时间的见解，并了解它们有助于规划应用程序应如何响应。
虽然如何获取事件负载的具体内容在事件网格、Azure Resource Graph（ARG）和实例元数据服务（IMDS）终结点之间有所不同，但无论选择哪种终结点，有效负载的内容都是相同的。 本部分介绍何时发出事件及其表示的不同状态。
VM 中断的计划事件时间线
处理计划事件、准备、影响和恢复有三个主要步骤。 当计划了影响 VM 的维护操作时，系统会发送含 EventStatus:"Scheduled" 和 NotBeforeTime 的计划事件。
NotBeforeTime 指示有影响的计划操作可能发生的最早时间。
警告期过期且维护操作准备好继续后，系统会发送含 EventStatus:"Started" 的新事件。 此事件表示 VM 可用性中断迫在眉睫，敏感工作负荷应已暂停或从 VM 中清空。 最后，操作完成后，将发送包含 EventStatus:"Completed" 的事件（事件网格，ARG）或空事件数组（IMDS），以指示可以安全地将敏感工作负荷还原到 VM。
虽然事件的确切时间不同，但下图提供了一个大致指南，说明典型的维护操作如何继续：
EventStatus:"Scheduled" 至批准超时：15 分钟
EventStatus:"Started" 到 EventStatus:Completed（从事件数组中移除的事件）：10 分钟
计划事件状态
计划事件中的 EventStatus 值会根据之前显示的整个时间线中断的进度而更改。 以下时间线显示事件在其生存期内可能采用的所有不同状态。 请务必注意，此关系图中的所有连接都是单向的。事件永远不会从已开始回到已计划状态，也不会在标记为已完成后重新启动。
当事件处于 EventStatus:"Scheduled" 状态时，需要采取措施来准备工作负载。 准备完成后，应使用计划的事件 API 批准该事件。 否则，当达到NotBefore时间时，该事件会被自动批准。 如果 VM 位于共享基础结构上，则系统会等待同一硬件上的所有其他租户也批准该作业，直至超时。 在从所有受影响的 VM 收集到审批或达到 NotBefore 时间后，Azure 会生成一个包含 EventStatus:"Started" 的新计划事件负载，并触发维护事件的开始。 当事件达到终端状态时，会将其从事件列表中删除。 这将是信号，提示您恢复您的虚拟机。
为不同的计划事件类型准备工作负荷的典型时间
将根据事件类型为每个事件计划将来的最小量时间。 大多数事件在达到最低通知时间之前立即发送，因此任何高可用性应用程序都必须设计为能够在这一时间范围内应对潜在影响。
事件类型
最短通知时间
冻结
15 分钟
重新 启动
15 分钟
重新部署
10 分钟
抢占
30 秒
终止雇用
用户可配置：5 到 15 分钟
这意味着，可至少在事件发生前的最小通知时间检测到事件的未来计划。 计划了事件后，它将在获批或 NotBefore 时间过去后进入 Started 状态。 但是，在极少数情况下，Azure在操作启动前取消操作。 在这种情况下，事件将从事件数组中删除，并且不会按以前计划产生影响。
确认预定事件
了解即将发生的事件并完成正常关闭逻辑后，可以确认未完成的事件。 此调用指示，Azure在可能的情况下可以缩短通知时间的最小值。 事件可能不会在批准后立即启动。 在某些情况下，Azure需要在继续执行该事件之前批准节点上托管的所有 VM。
确认事件后，即可允许事件针对事件中的所有资源继续进行，而不仅仅是确认该事件的 VM。 因此，可以选择一个领导者来协调确认，这可能与资源字段中的第一台计算机一样简单。
确认可以发送到任何 VM 中的 IMDS 终结点，也可以通过维护资源提供程序 （MRP） REST API 终结点发送。 Azure将任一终结点的审批请求视为事件可以启动。 可以从 IMDS 终结点接收事件并通过 MRP REST 终结点批准。
异常情况
为了确保应用程序使用计划事件满足其可用性目标，有几个唯一的情况很少发生，但应该做好以下准备：
预测硬件故障：在某些情况下，Azure可以预测由于硬件退化而导致的主机故障，并通过计划迁移来尝试缓解对您的服务造成的中断。 受影响的虚拟机会收到计划事件，该事件的 NotBefore 通常是将来几天的时间。 实际时间因预测失败风险评估而异。 Azure尽量提前七天发出通知。 实际警告时间会有所不同，如果预测表明硬件即将发生故障的可能性很高，则可能会更小。 若要在系统启动的迁移前硬件发生故障时将服务的风险降到最低，建议确认事件，以便尽快将虚拟机重新部署到新硬件。
Hardware Failure：如果主机节点遇到硬件故障，Azure会绕过最低通知期，并立即开始受影响虚拟机的恢复过程。 当受影响的 VM 无法响应时，此立即操作可减少恢复时间。 在恢复过程中，为所有受影响的 VM 创建一个事件，其中包含 EventType = Redploy 和 EventStatus = Started。
取消的事件：Azure 监控整个运营的维护操作，并在极少数情况下，确定维护操作在计划后执行的风险过高而无法进行。 在这种情况下，计划事件会直接从 EventStatus:Scheduled 变为取消。 在这些情况下，VM 不会遇到任何可用性中断。
已启动状态期间的多重影响：虽然事件仍处于 EventStatus:Started 状态，但持续时间短的影响可能会比计划事件中公布的影响多。 这些影响不会在事件移动到 EventStatus:Completed 之后发生，我们建议在事件标记为已完成之前不还原任何敏感工作负荷。
来宾 OS 更新：只有支持内存保留更新的常规用途 VM 大小支持针对虚拟机规模集来宾 OS 升级或重置映像的计划事件。 它不适用于 G、M、N 和 H 系列。 默认情况下，有关虚拟机规模集来宾操作系统升级或映像重置的计划事件处于禁用状态。 若要在受支持的 VM 大小上为这些操作启用计划事件，请先使用 OSImageNotificationProfile 启用它们。
用户启动的维护的计划事件
默认情况下，通过Azure门户、API、CLI 或 PowerShell 启动的 VM 维护会导致计划事件。 与所有类型的事件一样，除非通过 POST 请求获得批准或 NotBefore 时间已过，否则用户触发的事件不会继续进行。 无论事件源如何，事件都允许工作负荷为即将发生的操作做好准备。 我们建议在主 VM 无响应的情况下，让主要 VM 和辅助 VM 进行通信和批准用户生成的计划事件。 立即批准事件可防止将应用程序恢复到良好状态时出现延迟。
如果 automaticallyApprove 属性在虚拟机规模集、VM 或可用性集配置文件中设置为 true，则Azure会自动批准用户启动的操作，具体取决于 VM 的部署方式。 如果 automaticallyApprove 设置为 true，则事件会立即进入 EventStatus:Started 状态，跳过计划状态。
"scheduledEventsPolicy: {
"userInitiatedRedeploy": { "automaticallyApprove": true },
"userInitiatedReboot": { "automaticallyApprove": true }
}
应用程序可以使用用户启动的事件来测试他们对计划事件的响应。 由于从门户重启 VM 会生成计划事件，因此可以生成一系列事件来测试应用程序对意外中断的响应。
计划事件终结点
计划事件可通过三个不同的终结点使用，具体取决于应用程序的需求和体系结构。 由于通信介质的限制，每个终结点提供相同的事件信息，但略有差异。 选择使用哪个端点，或者是否使用多个端点，取决于哪个最适合您的应用程序和团队进行使用。
IMDS （Windows + Linux）
实例元数据服务（IMDS）使用可从 VM 内部访问的 REST 终结点公开有关运行 VM 的信息。 此信息通过不可路由的 IP 提供，不会在 VM 外部公开。 系统会将事件信息广播到同一虚拟机规模集放置组或可用性集中的所有 VM。
这适用于云原生工作负荷，其中每个 VM 可以随时进入或离开群集，例如容器化工作负荷。 每个 VM 可以监视计划事件的端点，以检查是否有影响其的新事件，然后如果即将有影响发生，可以从群集中删除其自身。
事件网格系统主题
Azure 事件网格是一项完全托管的 Pub Sub 消息分发服务，可提供灵活的消息使用模式。 系统主题是表示来自Azure服务的事件的预定义主题，例如 VM、存储或资源管理器。 如果要监视 VM 的计划事件，可以订阅 Microsoft.Maintenance.ScheduledEvents 系统主题，并在发生影响任何 VM 的事件时收到通知。 这适用于集中控制系统，其中需要由单个控制器做出故障转移决策。
Azure Resource Graph
Azure Resource Graph（ARG）可让开发人员在多个订阅中大规模调查 Azure 资源及其属性。 它专为复杂的查询和分析而设计，提供资源及其关系的综合视图。 ARG 很有助于在您的订阅中对所有虚拟机的历史记录进行大规模查询，或者将其与其他工具集成。
详细计划事件架构
无论从中传递的终结点如何，计划事件都包含相同的信息。 这种灵活性使你可以选择最适合应用程序的终结点。 以下部分概述了每个事件中提供的信息以及示例事件。
计划事件属性
财产
说明
文档化身
事件数组更改时增加的整数。 具有相同化身的文档包含相同的事件信息，当事件发生更改时，化身会递增。
EventId
事件的唯一全局标识符。
事件类型
此事件的预期影响。 价值观：
Freeze：虚拟机计划暂停几秒钟。 CPU 和网络连接可能会暂停，但对内存或打开的文件没有影响。
Reboot：虚拟机计划重新启动（非持久性内存丢失）。 在极少数情况下，被安排执行事件类型为“重新启动”的虚拟机可能会遇到冻结事件，而不是重新启动。
Redeploy：虚拟机计划移动到另一个节点（临时磁盘丢失）。
Preempt：正在删除现成虚拟机（临时磁盘将丢失）。 本次活动是在尽力而为的基础上提供的
Terminate：Azure已安排删除该虚拟机。
资源类型
此事件影响的资源类型。 价值观：VirtualMachine
Resources
此事件影响的资源列表。 示例： [“FrontEnd_IN_0”、“BackEnd_IN_0”]
事件状态
此事件的状态。 价值观：
Scheduled：此事件计划在属性中指定的 NotBefore 时间之后启动。
Started：该事件已开始。
Completed：（仅限 Event Grid 和 ARG）执行维护操作后事件已成功完成。
Canceled：（仅事件网格和 ARG）：计划影响未按计划发生，并且 VM 在计划时间内未受到影响。
NotBefore
在可以启动此事件之前所要经过的时间。 此活动保证不会在此时间之前开始。 如果事件后的事件启动，则为空白。 示例： 2016年9月19日星期一 18：29：47 GMT
说明
此事件的说明。 示例： 主机服务器正在进行维护。主机服务器基础结构正在进行维护。由于正在执行内存保留的实时迁移操作，虚拟机被暂停中。虚拟机将按照授权用户的要求重启。主机服务器正在进行紧急修复。
事件源
事件的发起方。 示例：
Platform：平台已启动此事件。
User：用户启动了此事件。
时长（秒）
事件导致的中断的预期持续时间。 在影响窗口内，可能会出现持续时间较短的次要影响。 示例：
9：事件造成的中断持续 9 秒。
0：事件不会中断 VM 或影响其可用性（例如，更新到网络）
-1：如果影响持续时间未知或不适用，则使用的默认值。
了解计划事件
若要了解为何计划了特定有影响的操作，在阅读事件时需要检查一些事项。
EventSource：指示Azure计划操作还是用户触发了操作。
说明：简要说明活动期间正在执行的操作，例如主机维护或实时迁移。 主机维护通常包括正在对主机执行的软件操作，例如更新主机上的 OS。
EventType：重新部署操作指示该操作要求 VM 在新主机上运行，而非实时迁移冻结事件表示 VM 保留在同一主机上。
虽然了解事件发生的原因对管理事件并不重要，但有时了解Azure中断 VM 的原因会很有帮助。 不过，若要管理对 VM 的影响，必须了解 EventType 和 DurationInSeconds 以确定应用程序应如何响应。
示例事件流
以下示例显示了计划事件传送到 IMDS 终结点的过程，其中该计划的实时迁移将在两个 VM 上同时发生。
Azure可确保资源数组中包含可以独立操作的最小 VM 集。 这意味着，如果计划的两个实时迁移可以单独批准，则数组中 Events 将有两个事件。 然而，在这种情况下，虚拟机需要在同一操作中进行迁移，因此它们都包含在资源数组中的同一事件中，并且在数组中有两个条目。
可能会注意到 DocumentIncarnation 从 3 增加到 4，同时从数组中删除事件，这表示影响时段已过。 一旦从事件列表中删除事件（或在事件网格终结点中标记为完成），除非创建了新的计划事件，否则不会对 VM 产生进一步的影响。 此时，应将工作负荷还原到 VM 并继续正常操作。
{
"DocumentIncarnation": 1,
"Events": [
]
}
{
"DocumentIncarnation": 2,
"Events": [
{
"EventId": "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
"EventStatus": "Scheduled",
"EventType": "Freeze",
"ResourceType": "VirtualMachine",
"Resources": [
"WestNO_0",
"WestNO_1"
],
"NotBefore": "Mon, 20 Apr 2026 22:26:58 GMT",
"Description": "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
"EventSource": "Platform",
"DurationInSeconds": 5
}
]
}
{
"DocumentIncarnation": 3,
"Events": [
{
"EventId": "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
"EventStatus": "Started",
"EventType": "Freeze",
"ResourceType": "VirtualMachine",
"Resources": [
"WestNO_0",
"WestNO_1"
],
"NotBefore": "",
"Description": "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
"EventSource": "Platform",
"DurationInSeconds": 5
}
]
}
{
"DocumentIncarnation": 4,
"Events": [
]
}
通过计划事件发送 OS 更新通知
常规用途 VM 大小支持虚拟机规模集来宾 OS 升级或重置映像的计划事件。 这些通知使得 VM 能够将先前的计划事件接收到维护操作，以便升级来宾 OS 或重置映像。 可以使用 OSImageNotificationProfile 启用这些事件，并在操作开始前设置 VM 的警告期限。
"scheduledEventsProfile": {
"osImageNotificationProfile": {
"enable": true,
"notBeforeTimeout": "PT15M"
}
G、M、N 和 H 系列 VM 不支持 OS 更新通知。
自动批准用户发起的计划事件
在某些情况下，你可能希望 Azure 代表你立即批准所有由用户发起的事件，例如从门户重新部署 VM。 通过在虚拟机规模集配置文件、可用性集配置文件或 VM 配置文件中设置属性来启用自动审批，具体取决于 VM 的部署方式。
设置自动审批行为时，您可以根据工作负荷的要求，选择自动批准所有重新启动操作、所有重新部署操作，或同时批准这两种类型的操作。
"scheduledEventsPolicy": {
"userInitiatedRedeploy": {
"automaticallyApprove": true
},
"userInitiatedReboot": {
"automaticallyApprove": true
}
}
自动批准事件时，不会创建与EventStatus:Scheduled相关的计划事件。 相反，该操作已获批准，仅创建包含 EventStatus:Started 和 EventStatus:Completed 的事件。 因此，请务必考虑是否存在某些情况，在这些情况下，运行应用程序的其他 VM 可能需要一些时间来做出反应，然后才可能被强制关闭。 例如，某些使用主-辅助体系结构的应用程序可能需要时间来先将辅助 VM 切换到主 VM，然后再强制关闭。
测试预定事件
测试应用程序对计划事件的响应的两种常见方法是手动触发用户模拟事件或使用模拟服务器。
可以通过Azure门户或Azure CLI手动触发重新部署和重新启动事件，方法是从 VM 边栏选项卡中选择“重新启动”或“重新部署”VM 选项。 这将创建一个事件并将其发送到您的负载。
影响多个 VM 的操作（例如主机更新）无法按需触发，因此可以改用模拟服务器。
vm-scheduled-events-mock-server提供了一个框架，用于通过重播真实事件流回开发和测试来测试应用程序对不同方案的响应。 默认情况下，服务器支持九种不同的方案，所有方案都从Azure中运行的 VM 捕获，并表示最常见的情况。 可以扩展方案以包含更多选项，具体取决于应用程序的特定特征。
相关内容
在 Windows 上使用 IMDS 的计划事件
使用 IMDS 在 Linux 上安排的事件
使用事件网格的计划事件
使用 Azure Resource Graph 的计划事件