Часто задаваемые вопросы о событиях pre и Post (предварительная версия)

Область применения: ✔️ виртуальные машины ✔️ ✔️ Linux под управлением Windows на локальных серверах с ✔️ поддержкой Azure Arc.

В этой статье представлены часто задаваемые вопросы о жизненном цикле событий предварительной и публикации (предварительная версия).

Как проверка конфигурацию предварительного и последующего события в расписании и его подсчете?

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.
2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.
3. На странице "Конфигурация обслуживания" выберите конфигурацию.
4. Выберите "Обзор" и проверка события обслуживания.

   • Если не настроены события предварительной и публикации, выберите "Настроить " для настройки.

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

Как просмотреть список событий предварительной и публикации, настроенных в конфигурации обслуживания?

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.

2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.

3. На странице "Конфигурация обслуживания" выберите конфигурацию.

4. На выбранной странице конфигурации обслуживания в разделе Параметры выберите "События", чтобы просмотреть созданные события до и публикации.

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

   

Как просмотреть список различных конечных точек, настроенных для предварительной и публикации событий в конфигурации обслуживания?

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.

2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.

3. На странице "Конфигурация обслуживания" выберите конфигурацию.

4. На выбранной странице конфигурации обслуживания в разделе Параметры выберите "События", чтобы просмотреть созданные события до и публикации.

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

   

Как проверка успешную доставку события до или публикации в конечную точку из сетки событий?

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.
2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.
3. На странице "Конфигурация обслуживания" выберите конфигурацию.
4. На выбранной странице конфигурации обслуживания в разделе Параметры выберите "События".
5. В разделе Essentials просмотрите метрики, чтобы просмотреть метрики для всех событий, входящих в подписку на события. В сетке количество метрик "Опубликованные события" должно соответствовать количеству метрик сопоставленных событий. Оба этих значения также должны соответствовать количеству доставленных событий.
6. Чтобы просмотреть метрики, относящиеся к событию предварительной или публикации, выберите имя события из сетки. Здесь количество метрик сопоставленных событий должно совпадать с числом доставленных событий.
7. Чтобы просмотреть время активации события, наведите указатель мыши на график строк. Подробнее.

Как проверка неудачную доставку событий до и отправки в конечную точку из сетки событий?

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.
2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.
3. На странице "Конфигурация обслуживания" выберите конфигурацию.
4. На выбранной странице конфигурации обслуживания в разделе Параметры выберите "События".
5. В разделе Essentials просмотрите метрики, чтобы просмотреть метрики для всех событий, входящих в подписку на события. Здесь вы узнаете, что число событий с ошибкой доставки метрик увеличивается.
6. Вы можете выполнить любую из следующих действий:
   1. Создайте оповещения Azure Monitor по этому количеству сбоев, чтобы получить уведомление об этом. Задайте оповещения для Сетка событий Azure метрик и журналов действий. (OR)
   2. Включите журналы диагностики, связав их с служба хранилища учетными записями или рабочей областью Log Analytics. Включите журналы диагностики для ресурсов сетки событий.

   Примечание.

   Вы можете в любое время настроить журналы и оповещения для успешных поставок.

Как проверка, если конечная точка была активирована в предварительной или последующей задаче?

Использование веб-перехватчиков с помощью модулей Runbook службы автоматизации

• Для запуска виртуальной машины требуется управляемое удостоверение службы автоматизации, чтобы иметь разрешения Microsoft.Compute/virtualMachines/start/action на виртуальных машинах, чтобы приступить к работе, и это разрешение включается в роль участника виртуальной машины.
• Убедитесь, что необходимо импортировать пакет PowerShell — ThreadJob с модулем версии:2.0.3.

1. Войдите в портал Azure и перейдите к учетной записи служба автоматизации Azure.

2. В учетной записи службы автоматизации в разделе "Автоматизация процессов" выберите Модули Runbook.

3. Выберите скрипт предварительной или публикации, связанный с веб-перехватчиком в сетке событий.

4. В обзоре можно просмотреть состояние задания Runbook. Время триггера должно составлять около 30 минут до времени начала расписания. Завершив задание, вы можете вернуться в тот же раздел, чтобы убедиться, что состояние завершено.

   

   После завершения можно убедиться, что процесс установки предварительного обновления завершен по мере планирования. Например, убедитесь, что виртуальная машина включена или отключена.

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

• Узнайте больше о том, как управлять модулями Runbook в служба автоматизации Azure.

С Функции Azure

• Чтобы отслеживать их выполнение, см. журналы настройки Функции Azure.

Как проверка, если скрипт в веб-перехватчиках с помощью модулей Runbook активируется из сетки событий?

1. Войдите в портал Azure и перейдите к учетной записи служба автоматизации Azure.

2. В учетной записи службы автоматизации в разделе "Автоматизация процессов" выберите Модули Runbook.

3. Выберите скрипт предварительной или публикации, связанный с веб-перехватчиком в сетке событий.

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

   

Как проверка отмену расписания?

Портал Azure

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.
2. В разделе "Управление" выберите компьютеры, конфигурации обслуживания.
3. На странице "Конфигурация обслуживания" выберите конфигурацию.
4. На выбранной странице конфигурации обслуживания в разделе Параметры выберите "Журнал действий", чтобы просмотреть созданные события предварительной и публикации.

   1. Если текущее расписание обслуживания было отменено, имя операции будет применять обновления к ресурсу.

      

   2. Выберите действие, чтобы просмотреть сведения, которые выполняет действие.

REST API

1. Поток отмены учитывается от T-40, когда событие предварительной проверки активируется до T-10. Подробнее.

   Чтобы вызвать API отмены, выполните следующие действия.

   C:\ProgramData\chocolatey\bin\ARMClient.exe put https://management.azure.com/<your-c-id-obtained-from-above>?api-version=2023-09-01-preview "{\"Properties\":{\"Status\": \"Cancel\"}}" -Verbose
   

2. Убедитесь, что необходимо вставить идентификатор корреляции задания обслуживания, чтобы отменить его, и вы увидите ответ в ИНТЕРФЕЙСе командной строки или API следующим образом:

   

Как подтвердить, является ли отмена пользователем или системой?

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

Следующий запрос позволяет просмотреть список виртуальных машин для заданного расписания или конфигурации обслуживания:

maintenanceresources  
| where type =~ "microsoft.maintenance/maintenanceconfigurations/applyupdates"  
| where properties.correlationId has "/subscriptions/<your-s-id> /resourcegroups/<your-rg-id> /providers/microsoft.maintenance/maintenanceconfigurations/<mc-name> /providers/microsoft.maintenance/applyupdates/"  
| order by name desc

Как проверка состояние конфигурации обслуживания?

Портал Azure

1. Войдите в портал Azure и перейдите в Диспетчер обновлений Azure.
2. В разделе "Управление" выберите "Журнал".
3. Перейдите на вкладку "Идентификатор обслуживания", чтобы просмотреть задания по конфигурациям обслуживания. Для соответствующего идентификатора выполнения обслуживания можно просмотреть состояние задания.
4. Выберите состояние, чтобы просмотреть сведения о задании.

REST API/CLI

1. Используйте следующий запрос Azure Resource Graph (ARG), чтобы просмотреть состояние задания в ARG.

    maintenanceresources  
    | where type =~ "microsoft.maintenance/maintenanceconfigurations/applyupdates"  
    | where properties.correlationId has "/subscriptions/<your-s-id> /resourcegroups/<your-rg-id> /providers/microsoft.maintenance/maintenanceconfigurations/<mc-name> /providers/microsoft.maintenance/applyupdates/"  
    | order by name desc	 
   

2. Убедитесь, что необходимо вставить идентификатор подписки, группу ресурсов и имя конфигурации обслуживания в приведенном выше запросе.

Почему запланированное выполнение было отменено системой?

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

1. Если конфигурация обслуживания имеет по крайней мере одну предварительную подписку на событие, а время расписания изменяется в течение 40-минутного периода до запланированного времени начала.
2. Если предварительное событие было создано в течение 40-минутного окна до запланированного времени начала.

Почему событие записи не было отправлено системой?

Если пользователь изменяет время выполнения расписания после активации предварительного события, событие записи не будет отправлено, так как запланированное время было заменено новым.

Примечание.

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

Следующие шаги

• Общие сведения о сценариях подготовки и публикации
• Управление событиями конфигурации предварительного и после обслуживания