Служба метаданных Azure: запланированные события для виртуальных машин Windows

Применимо к: ✔️ Виртуальные машины Windows ✔️ Гибкие масштабируемые наборы ✔️ Универсальные масштабируемые наборы

Запланированные события — это служба метаданных Azure, которая дает время вашему приложению для подготовки к обслуживанию виртуальной машины. Эта служба предоставляет сведения о предстоящем событии обслуживания (например, о перезагрузке), чтобы приложение могло подготовиться к ним и ограничить перебои в работе. Она доступна для всех типов виртуальных машин Azure, включая PaaS и IaaS (как для Windows, так и для Linux).

Сведения о запланированных событиях в Linux см. в разделе "Запланированные события" для виртуальных машин Linux.

Запланированные события предоставляют упреждающие уведомления о предстоящих событиях для реактивной информации о событиях, произошедших в прошлом, см. сведения о доступности виртуальных машин в Azure Resource Graph и создании правила генерации оповещений о доступности для виртуальной машины Azure.

Замечание

Запланированные события обычно доступны во всех регионах Azure. Сведения о последней версии и регионе см. в разделе "Доступность версий и регионов ".

Зачем использовать запланированные события?

Многие приложения могут воспользоваться временем для подготовки к обслуживанию виртуальных машин. Время можно использовать для выполнения конкретных приложений задач, которые повышают доступность, надежность и удобство обслуживания, включая:

• Контрольная точка и восстановление.
• Очистка подключений.
• Отработка отказа первичной реплики.
• Удаление из пула балансировщика нагрузки.
• Ведение журнала событий.
• Корректное завершение работы.

С помощью запланированных событий приложение может обнаружить, когда будет выполняться обслуживание и запускать задачи, чтобы ограничить его влияние.

Функция "Запланированные события" предоставляет события в следующих вариантах использования:

• Обслуживание, инициированное платформой (например, перезагрузка виртуальной машины, динамическая миграция или обновления с сохранением памяти для узла).
• Виртуальная машина работает на деградирующем оборудовании узла, которое, по прогнозам, может скоро выйти из строя.
• Виртуальная машина выполнялась на узле, в котором произошел сбой оборудования.
• Обслуживание, инициированное пользователем (например, перезапуск или повторное развертывание виртуальной машины).
• Вытеснение экземпляров Spot ВМ и экземпляров Spot-набора масштабирования.

Основы

Служба метаданных предоставляет сведения о запуске виртуальных машин с помощью конечной точки REST, доступной на виртуальной машине. Сведения доступны через неизменяемый IP-адрес и не предоставляются за пределами виртуальной машины.

Область действия

Запланированные события доставляются следующим получателям и могут быть ими подтверждены:

• Автономные виртуальные машины.
• Все виртуальные машины в облачной службе Azure (классическая модель).
• Все виртуальные машины в группе доступности.
• Все виртуальные машины в группе размещения масштабируемого набора.

Запланированные события для всех виртуальных машин (виртуальных машин) во всей группе доступности или группе размещения для масштабируемого набора виртуальных машин предоставляются всем остальным виртуальным машинам в одной группе или наборе независимо от использования зоны доступности.

В результате проверьте в событии поле Resources, чтобы определить, какие виртуальные машины затронуты.

Замечание

Виртуальные машины с ускорением GPU в масштабируемом наборе с использованием одного домена сбоя (FD = 1) получают только запланированные события для затронутого ресурса. События не будут передаваться на все виртуальные машины в той же группе размещения.

Обнаружение конечных точек

Для виртуальных машин с поддержкой виртуальной сети служба метаданных доступна из статического неизменяемого IP-адреса 169.254.169.254. Полная конечная точка для последней версии запланированных событий:

http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Если виртуальная машина не создана в виртуальной сети, что является вариантом по умолчанию для облачных служб и классических виртуальных машин, требуется другая логика для определения IP-адреса, который будет использоваться. Сведения о том, как обнаружить конечную точку узла, см. в этом примере.

Доступность версий и регионов

Служба запланированных событий имеет версии. Версии обязательны; текущая версия 2020-07-01.

Версия	Тип выпуска	Регионы	Заметки о релизе
01.07.2020	Общая доступность	Все	Добавлена поддержка длительности событий
01.08.2019	Общая доступность	Все	Добавлена поддержка EventSource
2019-04-01	Общая доступность	Все	Добавлена поддержка описания событий
2019-01-01	Общая доступность	Все	Добавлена поддержка события "Terminate" типа EventType для масштабируемых наборов виртуальных машин.
2017-11-01	Общая доступность	Все	Добавлена поддержка вытеснения точечных виртуальных машин EventType "Preempt"
2017-08-01	Общая доступность	Все	Удалено предварительно заданное подчеркивание из имен ресурсов для виртуальных машин IaaS Требование заголовка метаданных для всех запросов
2017-03-01	Предпросмотр	Все	Первый релиз

Замечание

Предыдущие предварительные выпуски запланированных событий поддерживают {latest} в качестве версии API. Этот формат больше не поддерживается и будет устарел в будущем.

Включение и отключение запланированных событий

Запланированные события включаются для вашей службы при первом запросе событий. Ожидайте задержку ответа в первом звонке до двух минут, и вы начнете получать события в течение 5 минут. Запланированные события отключаются для вашего сервиса, если он не выполняет запрос к конечной точке в течение 24 часов.

Обслуживание, инициированное пользователем

Обслуживание виртуальной машины, инициированное пользователем, через портал Azure, API, CLI или PowerShell, приводит к запланированному событию. Затем вы можете протестировать логику подготовки обслуживания в приложении, и приложение может подготовиться к обслуживанию, инициированного пользователем.

При перезапуске виртуальной машины запланировано событие с типом Reboot . При повторном развертывании виртуальной машины запланировано событие с типом Redeploy . Обычно события с источником событий пользователя можно немедленно утвердить, чтобы избежать задержки в действиях, инициированных пользователем. Мы советуем взаимодействовать с первичной и вторичной виртуальной машиной и утверждать созданные пользователем запланированные события, если основная виртуальная машина не отвечает. Немедленное утверждение событий предотвращает задержки при восстановлении приложения в нормальное состояние.

Запланированные события для обновлений гостевых ОС в масштабируемых наборах виртуальных машин поддерживаются только для виртуальных машин общего назначения, которые поддерживают обновления с сохранением памяти. Он не работает для серии G, M, N и H. Запланированные события для обновлений и повторных образов гостевой ОС в масштабируемых наборах виртуальных машин отключены по умолчанию. Чтобы включить запланированные события для этих операций с поддерживаемыми размерами виртуальных машин, сначала включите их с помощью OSImageNotificationProfile.

Использование API

Общий обзор

Существует два основных компонента для обработки запланированных событий, подготовки и восстановления. Все текущие запланированные события, влияющие на виртуальную машину, доступны для чтения через конечную точку запланированных событий IMDS. Когда событие достигает состояния терминала, оно удаляется из списка событий. На следующей схеме показаны различные переходы состояния, которые могут выполняться одним запланированным событием:

Для событий в состоянии EventStatus:"Scheduled" необходимо выполнить шаги по подготовке рабочей нагрузки. После завершения подготовки необходимо утвердить событие с помощью API запланированных событий. В противном случае событие автоматически утверждается, когда наступает время, установленное в параметре NotBefore. Если виртуальная машина находится в общей инфраструктуре, система будет ожидать, пока все остальные клиенты на том же оборудовании не утвердят задание или не истечет время ожидания. После получения подтверждений со всех затронутых виртуальных машин или достижения времени NotBefore, Azure создает новый запланированный пакет события с EventStatus: "Started" и инициирует начало события обслуживания. Когда событие достигает состояния терминала, оно удаляется из списка событий. Это служит сигналом для клиента для восстановления виртуальных машин.

Код psudeo демонстрирует процесс чтения и управления запланированными событиями в приложении:

current_list_of_scheduled_events = get_latest_from_se_endpoint()
#prepare for new events
for each event in current_list_of_scheduled_events:
  if event not in previous_list_of_scheduled_events:
    prepare_for_event(event)
#recover from completed events
for each event in previous_list_of_scheduled_events:
  if event not in current_list_of_scheduled_events:
    receover_from_event(event)
#prepare for future jobs
previous_list_of_scheduled_events = current_list_of_scheduled_events

Так как запланированные события часто используются для приложений с высокими требованиями к доступности, существует несколько исключительных случаев, которые следует учитывать:

1. После завершения запланированного события и его удаления из массива, никаких дополнительных воздействий не произойдет, если не будет нового события, включая другое событие со статусом EventStatus:"Scheduled"
2. Azure Monitor отслеживает операции обслуживания по всему флоту и в редких случаях определяет, что связанный с операцией риск слишком высок для применения. В этом случае запланированное событие сразу же удаляется из массива событий, минуя стадию "запланировано"
3. Если происходит сбой оборудования, Azure пропускает состояние "Запланировано" и немедленно переходит в состояние EventStatus:"Started".
4. Хотя событие по-прежнему находится в состоянии "EventStatus:Started", может произойти ещё одно воздействие с меньшей продолжительностью, чем было заявлено в расписании события.

В рамках гарантии доступности Azure виртуальные машины в разных областях отказа не будут затронуты плановыми операциями обслуживания одновременно. Однако их операции могут выполняться последовательно. Виртуальные машины в одном домене сбоя могут получать запланированные события с помощью EventStatus:"Scheduled" вскоре после завершения обслуживания другого домена сбоя. Независимо от выбранной архитектуры всегда проверяйте наличие новых событий, ожидающих обработки от виртуальных машин.

Хотя точные сроки событий зависят, на следующей схеме представлено грубое руководство по тому, как выполняется обычная операция обслуживания:

• EventStatus: "Scheduled" до Истечение времени на утверждение: 15 минут
• Длительность воздействия: 7 секунд
• EventStatus:"Started" до "Завершено" (событие удалено из массива событий): 10 минут

Все операции, влияющие на доступность виртуальной машины, создают запланированное событие, однако не все запланированные события отображаются в других поверхностях Azure, таких как журналы действий Azure или работоспособность ресурсов. Регулярно проверяя запланированные события, вы сможете получить наиболее up-toсведения о предстоящих последствиях для виртуальных машин.

Заголовки

При запросе службы метаданных необходимо указать заголовок Metadata:true , чтобы убедиться, что запрос не был перенаправлен непреднамеренно. Заголовок Metadata:true необходим для всех запросов на запланированные события. Сбой включения заголовка в запрос приводит к ответу "Недопустимый запрос" из службы метаданных.

Запрос событий

Вы можете запросить запланированные события, выполнив следующий вызов:

Пример Bash

curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Пример для PowerShell

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | ConvertTo-Json -Depth 64

Пример для Python

import json
import requests

metadata_url ="http://169.254.169.254/metadata/scheduledevents"
header = {'Metadata' : 'true'}
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

Ответ содержит массив запланированных событий. Пустой массив означает, что в настоящее время события не запланированы. В случае, когда есть запланированные события, ответ содержит массив событий.

{
    "DocumentIncarnation": {IncarnationID},
    "Events": [
        {
            "EventId": {eventID},
            "EventType": "Reboot" | "Redeploy" | "Freeze" | "Preempt" | "Terminate",
            "ResourceType": "VirtualMachine",
            "Resources": [{resourceName}],
            "EventStatus": "Scheduled" | "Started",
            "NotBefore": {timeInUTC},       
            "Description": {eventDescription},
            "EventSource" : "Platform" | "User",
            "DurationInSeconds" : {timeInSeconds},
        }
    ]
}

Свойства события

Недвижимость	Описание
Воплощение документа	Целое число, которое увеличивается при изменении массива событий. Документы с одной и той же инкарнацией содержат те же сведения о событии, а при изменении события инкарнация увеличивается.
EventId	Глобальный уникальный идентификатор для этого события. Пример: 602d9444-d2cd-49c7-8624-8643e7171297
Тип события	Ожидаемое влияние этого события. Значения: Freeze: запланирована приостановка виртуальной машины на несколько секунд. Подключение к ЦП и сети может быть приостановлено, но не влияет на память или открытые файлы. Reboot: виртуальная машина запланирована на перезагрузку (не сохраняемая память теряется). В редких случаях виртуальная машина, запланированная для EventType:"Перезагрузка", может столкнуться с событием замораживания вместо перезагрузки. Следуйте приведенным выше инструкциям, чтобы узнать, завершено ли событие и безопасно восстановить рабочую нагрузку. Redeploy: Запланировано перемещение виртуальной машины на другой узел (временные диски будут потеряны). Preempt: Виртуальная машина Spot удаляется (временные диски будут потеряны). Это событие предоставляется на основе принципа наилучших усилий. Terminate: виртуальная машина планируется удалить.
ТипРесурса	Тип ресурса, который влияет на это событие. Значения: VirtualMachine
Ресурсы	Список ресурсов, влияющих на это событие. Пример: ["FrontEnd_IN_0", "BackEnd_IN_0"]
Статус события	Состояние этого события. Значения: Scheduled: это событие планируется начать после времени, указанного в свойстве NotBefore . Started: это событие началось. Ни Completed, ни аналогичный статус никогда не предоставляется. Событие больше не возвращается после завершения события.
Не ранее	Время, после которого это событие может начаться. Это событие гарантированно не начнется до этого времени. Будет пустым, если событие произойдет после начала события. Пример: Mon, 19 Сентября 2016 18:29:47 GMT
Описание	Описание этого события. Пример: Сервер узла проходит обслуживание. Инфраструктура сервера проходит обслуживание. Виртуальная машина приостановлена из-за операции динамической миграции с сохранением памяти. Виртуальная машина будет перезапущена по запросу авторизованного пользователя. Сервер узла проходит аварийное восстановление.
ИсточникСобытий	Инициатор события. Пример: Platform: Платформа инициировала это событие. User: пользователь инициировал это событие.
ПродолжительностьВСекундах	Ожидаемая длительность прерывания, вызванного событием. Во время кратковременного периода воздействия могут проявляться вторичные последствия. Пример: 9: прерывание, вызванное событием, длится в течение 9 секунд. 0: событие не прерывает виртуальную машину или не влияет на ее доступность (например, обновление в сети) -1: значение по умолчанию, используемое, если длительность воздействия является неизвестной или неприменимой.

Планирование событий

Каждое событие запланировано на минимальное время в будущем на основе типа события. Это время отражается в свойстве события NotBefore .

Тип события	Минимальное уведомление
Блокировка	15 минут
Перезагрузка	15 минут
Повторное развертывание	10 минут
Выгрузка	30 секунд
Прекращать	Настраиваемый пользователем: 5–15 минут

Это означает, что вы можете определить будущее расписание события по крайней мере по минимальному времени уведомления до возникновения события. После того как событие запланировано, оно перейдёт в состояние Started после его утверждения или когда пройдет NotBefore время. Однако в редких случаях операция отменяется Azure перед началом работы. В этом случае событие удаляется из массива событий, и влияние не будет происходить как ранее запланировано.

Замечание

В некоторых случаях Azure может прогнозировать сбой узла из-за ухудшения оборудования и пытается устранить нарушения работы службы путем планирования миграции. Затронутые виртуальные машины получат запланированное событие с NotBefore, которое обычно произойдет через несколько дней. Фактическое время зависит от прогнозируемой оценки риска сбоя. Azure пытается предоставить 7 дней предварительного уведомления, когда это возможно. Фактическое время уведомления меняется и может быть короче, если есть высокая вероятность сбоя оборудования неминуемо. Чтобы свести к минимуму риск для службы в случае сбоя оборудования до миграции, инициированной системой, рекомендуется самостоятельно развернуть виртуальную машину как можно скорее.

Замечание

Если узел испытывает сбой оборудования, Azure обходит минимальный период уведомления и немедленно начинает процесс восстановления затронутых виртуальных машин. Это сокращает время восстановления в случае, если затронутые виртуальные машины не могут реагировать. Во время процесса восстановления создается событие для всех затронутых виртуальных машин и EventType = RebootEventStatus = Started.

Частота опроса

Конечную точку можно опрашивать так часто или редко, как пожелаете. Тем не менее, чем дольше время между запросами, тем больше времени вы потенциально теряете, чтобы реагировать на предстоящее событие. Большинство событий имеют от 5 до 15 минут предварительного уведомления, хотя в некоторых случаях предварительное уведомление может быть не менее 30 секунд. Чтобы обеспечить максимальное количество времени для принятия мер по устранению неполадок, рекомендуется провести опрос службы один раз в секунду.

Запуск события

После того как вы узнаете о предстоящем событии и завершите логику его плавного завершения, вы можете утвердить ожидающее подтверждение событие, сделав вызов службы метаданных с помощью POSTEventId. Этот вызов указывает Azure, что он может сократить минимальное время уведомления (по возможности). Событие может не начинаться сразу после утверждения. В некоторых случаях Azure требует утверждения всех виртуальных машин, размещенных на узле, прежде чем продолжить событие.

В тексте POST запроса ожидается следующий пример JSON. Запрос должен содержать список StartRequests. Каждый StartRequest содержит EventId событие, которое требуется ускорить:

{
	"StartRequests" : [
		{
			"EventId": {EventId}
		}
	]
}

Сервис всегда возвращает успешный код 200, если передан валидный идентификатор события, даже если другая виртуальная машина уже одобрила это событие. Код ошибки 400 указывает, что заголовок запроса или полезные данные были неправильно сформированы.

Замечание

События не произойдут, если они не будут утверждены через сообщение POST или пока не истечет время NotBefore. Это включает в себя события, активированные пользователем, например перезапуск виртуальной машины с портала Azure.

Пример Bash

curl -H Metadata:true -X POST -d '{"StartRequests": [{"EventId": "f020ba2e-3bc0-4c40-a10b-86575a9eabd5"}]}' http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Пример для PowerShell

Invoke-RestMethod -Headers @{"Metadata" = "true"} -Method POST -body '{"StartRequests": [{"EventId": "5DD55B64-45AD-49D3-BBC9-F57D4EA97BD7"}]}' -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 | ConvertTo-Json -Depth 64

Пример для Python

import json
import requests

def confirm_scheduled_event(event_id):  
   # This payload confirms a single event with id event_id
   payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
   response = requests.post("http://169.254.169.254/metadata/scheduledevents", 
                            headers =  {'Metadata' : 'true'}, 
                            params = {'api-version':'2020-07-01'}, 
                            data = payload)    
   return response.status_code

Замечание

Подтверждение события позволяет событию продолжаться для всех Resources в событии, а не только виртуальной машине, которая подтверждает событие. Таким образом, вы можете выбрать лидера для координации подтверждения, и это может быть так же просто, как выбрать первую машину в поле Resources.

Примеры ответов

Пример событий, когда две виртуальные машины были живыми перемещены на другой узел, приведен ниже.

DocumentIncarnation изменяется каждый раз, когда появляется новая информация в Events. Подтверждение проведения мероприятия позволит заморозку для WestNO_0 и WestNO_1.

{
    "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, 11 Apr 2022 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":  [
               ]
}

Пример на Python

Пример запрашивает службу метаданных для запланированных событий и утверждает каждое выдающееся событие. Код можно найти в репозитории vm-scheduled-events-mock-server в файле Listener.py.

#!/usr/bin/python
import json
import requests
from time import sleep

# The URL to access the metadata service
metadata_url ="http://169.254.169.254/metadata/scheduledevents"
# This must be sent otherwise the request will be ignored
header = {'Metadata' : 'true'}
# Current version of the API
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

def confirm_scheduled_event(event_id):  
    # This payload confirms a single event with id event_id
    # You can confirm multiple events in a single request if needed      
    payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
    response = requests.post(metadata_url, 
                            headers= header,
                            params = query_params, 
                            data = payload)    
    return response.status_code

def log(event): 
    # This is an optional placeholder for logging events to your system 
    print(event["Description"])
    return

def advanced_sample(last_document_incarnation): 
    # Poll every second to see if there are new scheduled events to process
    # Since some events may have necessarily short warning periods, it is 
    # recommended to poll frequently
    found_document_incarnation = last_document_incarnation
    while (last_document_incarnation == found_document_incarnation):
        sleep(1)
        payload = get_scheduled_events()    
        found_document_incarnation = payload["DocumentIncarnation"]        
        
    # We recommend processing all events in a document together, 
    # even if you won't be actioning on them right away
    for event in payload["Events"]:

        # Events that already started, logged for tracking
        if (event["EventStatus"] == "Started"):
            log(event)
            
        # Approve all user initiated events. These are typically created by an 
        # administrator and approving them immediately can help to avoid delays 
        # in admin actions
        elif (event["EventSource"] == "User"):
            confirm_scheduled_event(event["EventId"])            
            
        # For this application, freeze events less that 9 seconds are considered
        # no impact. This will immediately approve them
        elif (event["EventType"] == "Freeze" and 
            int(event["DurationInSeconds"]) >= 0  and 
            int(event["DurationInSeconds"]) < 9):
            confirm_scheduled_event(event["EventId"])
            
        # Events that may be impactful (for example reboot or redeploy) may need custom 
        # handling for your application
        else: 
            #TODO Custom handling for impactful events
            log(event)
    print("Processed events from document: " + str(found_document_incarnation))
    return found_document_incarnation

def main():
    # This will track the last set of events seen 
    last_document_incarnation = "-1"

    input_text = "\
        Press 1 to poll for new events \n\
        Press 2 to exit \n "
    program_exit = False 

    while program_exit == False:
        user_input = input(input_text)    
        if (user_input == "1"):                        
            last_document_incarnation = advanced_sample(last_document_incarnation)
        elif (user_input == "2"):
            program_exit = True       

if __name__ == '__main__':
    main()

Тестирование запланированных событий

Два распространенных способа тестирования ответов приложений на запланированные события вручную активируют имитированные события пользователя или используют макетный сервер.

Вы можете вручную активировать события повторного развертывания и перезагрузки с помощью портала Azure или Azure CLI, выбрав параметр "перезагрузка" или "повторное развертывание" виртуальной машины в колонке виртуальной машины. Это создаст событие и отправит его в ваш рабочий процесс.

Операции, влияющие на несколько виртуальных машин, таких как обновления узлов, нельзя активировать по запросу, чтобы вместо этого можно было использовать макетный сервер. Vm-scheduled-events-mock-server предоставляет платформу для тестирования ответа приложения на различные сценарии путем повторного воспроизведения реальных событий обратно для разработки и тестирования. По умолчанию сервер поддерживает 9 различных сценариев, все захваченные из виртуальных машин, работающих в Azure и представляющие наиболее распространенные случаи. Сценарии можно расширить, чтобы включить дополнительные параметры в зависимости от конкретных характеристик приложений.

Дальнейшие шаги

• Ознакомьтесь с примерами кода для Scheduled Events в репозитории GitHub с метаданными запланированных событий Azure.
• Просмотрите примеры кода запланированных событий Node.js в репозитории GitHub с примерами Azure.
• Узнайте больше об API, которые доступны в службе метаданных экземпляра.
• Узнайте о плановом обслуживании виртуальных машин Windows в Azure.
• Узнайте, как отслеживать запланированные события для виртуальных машин с помощью Log Analytics.
• Узнайте, как регистрировать запланированные события с помощью Центров событий Azure в репозитории GitHub примеров Azure.
• Используйте виртуальную машину-scheduled-events-mock-server для тестирования ответа приложения на распространенные сценарии запланированных событий.