Настройка местоположения для неудавшихся сообщений и политики повторных попыток выполнения

При создании подписки на события, можно настроить параметры доставки событий. В этой статье объясняется, как настроить место для недоставленных сообщений и параметры повторных попыток. Сведения об этих возможностях см. в разделе Доставка и повторные попытки доставки сообщений сетки событий.

Примечание.

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

Настроить место хранения недоставленных сообщений

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

Перед выполнением команд в этой статье необходимо создать учетную запись и контейнер объектов Blob в хранилище. Event Grid создает объекты BLOB в этом контейнере. Имена BLOB-объектов содержат имя подписки на Event Grid, написанное заглавными буквами. например, если имя подписки — My-Blob-Subscription, имена blobs необработанных писем содержат MY-BLOB-SUBSCRIPTION (myblobcontainer/MY-BLOB-SUBSCRIPTION/2019/8/8/5/111111111-1111-1111-1111-111111111111.json). Такое поведение предназначено для защиты от различий в обработке обращений между службами Azure. В примере .../2019/8/8/5/... представляет ненулевое заполненное значение даты и часа (UTC): .../YYYY/MM/DD/HH/....'. Необработанные сообщения содержат одно или несколько событий в массиве, что является важной характеристикой при обработке таких сообщений.

Портал Azure

При создании подписки на события вы можете включить обработку недоставленных сообщений на вкладке "Дополнительные функции", как показано на рисунке ниже. После включения функции укажите контейнер BLOB-объектов, в котором хранятся недоставленные события и подписка Azure с хранилищем BLOB-объектов.

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

Снимок экрана: параметры конфигурации мёртвых сообщений на вкладке

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

Снимок экрана: параметры недоставленных букв на вкладке

Azure CLI

containername=testcontainer

topicid=$(az eventgrid topic show --name demoTopic -g gridResourceGroup --query id --output tsv)
storageid=$(az storage account show --name demoStorage --resource-group gridResourceGroup --query id --output tsv)

az eventgrid event-subscription create \
  --source-resource-id $topicid \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --deadletter-endpoint $storageid/blobServices/default/containers/$containername

Для отключения сохранения недоставленных сообщений выполните эту команду повторно, чтобы создать подписку на события, но не указывайте значение для deadletter-endpoint. Удалять подписку на события не нужно.

Примечание.

Если вы используете Azure CLI на локальном компьютере, используйте Azure CLI версии 2.0.56 или более поздней. Инструкции по установке последней версии Azure CLI см. в этой статье.

PowerShell

$containername = "testcontainer"

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id
$storageid = (Get-AzStorageAccount -ResourceGroupName gridResourceGroup -Name demostorage).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -DeadLetterEndpoint "$storageid/blobServices/default/containers/$containername"

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

Примечание.

Если вы используете Azure PowerShell на локальном компьютере, используйте Azure PowerShell версии 1.1.0 или более поздней. Скачайте и установите последнюю версию Azure PowerShell из загрузок Azure.

Установка политики повтора

При создании подписки на Event Grid можно установить значения для того, как долго Event Grid должна пытаться доставить событие. По умолчанию Event Grid выполняет до 30 попыток в течение 24 часов (1440 минут). Вы можете задать любое из этих значений для подписки сетки событий. Значение времени жизни события должно быть целым числом от 1 до 1440. Значение для максимального количества попыток должно быть целым числом от 1 до 30.

Настроить интервал повтора невозможно.

Портал Azure

При создании подписки на событие можно настроить параметры политики повторных попыток на вкладке "Дополнительные функции ".

Снимок экрана: параметры конфигурации политики повторных попыток на вкладке

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

Снимок экрана: параметры политики повторных попыток на вкладке

Azure CLI

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

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --event-ttl 720

Чтобы установить максимальное количество попыток на значение, отличное от 30, используйте:

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --max-delivery-attempts 18

Примечание.

Если заданы оба параметра event-ttl и max-deliver-attempts, служба Event Grid использует тот, который истекает первым, для определения времени прекращения доставки событий. Например, если установить время жизни равным 30 минутам и задать максимум 5 попыток доставки. Если событие не доставлено через 30 минут или после пяти попыток, в зависимости от того, что произойдет первым, событие будет помещено в мертвую очередь. Если вы установите максимальное число попыток доставки на 10, с учётом экспоненциального расписания повторных попыток, максимум шесть попыток доставки произойдут до момента, когда истечет 30-минутный TTL. Поэтому установка предела в 10 попыток не окажет влияния в данном случае, и события будут помещены в очередь недоставленных после 30 минут.

PowerShell

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

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -EventTtl 720

Чтобы установить максимальное количество попыток на значение, отличное от 30, используйте:

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -MaxDeliveryAttempt 18

Примечание.

Если заданы оба параметра event-ttl и max-deliver-attempts, служба Event Grid использует тот, который истекает первым, для определения времени прекращения доставки событий. Например, если установить время жизни равным 30 минутам и задать максимум 5 попыток доставки. Если событие не доставлено через 30 минут или после пяти попыток, в зависимости от того, что произойдет первым, событие будет помещено в мертвую очередь. Если вы установите максимальное число попыток доставки на 10, с учётом экспоненциального расписания повторных попыток, максимум шесть попыток доставки произойдут до момента, когда истечет 30-минутный TTL. Поэтому установка предела в 10 попыток не окажет влияния в данном случае, и события будут помещены в очередь недоставленных после 30 минут.