Доставка и повторные попытки доставки сообщений в Event Grid

Сетка событий обеспечивает надежную доставку. Он старается немедленно доставить каждое сообщение по крайней мере один раз для каждой соответствующей подписки. Если конечная точка подписчика не подтверждает получение события или произошла ошибка, Сетка событий повторяет попытку доставки на основе предопределенного расписания повтора и политики повтора. По умолчанию Служба "Сетка событий" передает одно событие в одно время подписчику. Однако полезная нагрузка — это массив с одним событием.

Расписание повторных попыток

Когда Event Grid получает ошибку при попытке доставки события, он решает, следует ли повторить доставку, переместить событие в мертвую очередь или удалить событие, опираясь на тип ошибки.

Если подписанный конечная точка возвращает ошибку, связанную с конфигурацией, которая не может быть исправлена повторными попытками (например, если конечная точка удалена), Event Grid либо помещает событие в очередь без доставки, либо удаляет событие, если очередь без доставки не настроена.

В следующей таблице описываются типы конечных точек и ошибок, для которых сетка событий не выполняет повторную доставку:

Если подписанная конечная точка возвращает ошибку, которая не указана в предыдущем списке, Event Grid повторяет доставку с помощью следующей политики:

Сетка событий ожидает ответа в течение 30 секунд после доставки сообщения. Через 30 секунд, если конечная точка не отвечает, Event Grid ставит сообщение в очередь для повторной отправки. Для доставки событий Event Grid использует политику повторной попытки с экспоненциальным увеличением задержки. Служба Event Grid повторяет попытку доставки по следующему расписанию, по принципу максимального старания:

• 10 секунд
• 30 секунд
• 1 минута
• 5 мин
• 10 минут
• 30 минут
• 1 ч
• 3 часов
• 6 часов
• Каждые 12 часов до 24 часов

Если конечная точка отвечает в течение 3 минут, Event Grid пытается удалить событие из очереди повторных попыток в меру возможностей, но дубликаты по-прежнему могут быть получены.

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

Политика повтора

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

• Максимальное число попыток. Значение должно быть целым числом от 1 до 30. Значение по умолчанию — 30.
• Срок жизни события (TTL) — значение должно быть целым числом в диапазоне от 1 до 1440. Значение по умолчанию — 1440 минут.

Пример использования команды интерфейса командной строки и PowerShell для настройки этих параметров см. в разделе Настройка политики повторов.

Пакетная обработка выходных данных

По умолчанию Сетка событий отправляет каждое событие подписчикам по отдельности. Каждый подписчик получает массив с одним событием. Сетку событий можно настроить так, чтобы события для доставки объединялись в пакеты. Это улучшит производительность HTTP в сценариях с большой пропускной способностью. Пакетная обработка отключена по умолчанию и ее можно включить для каждой подписки.

Политика пакетной обработки

У пакетной доставки есть два параметра:

• Максимальное количество событий на пакет — максимальное число событий сетки событий доставляется на каждый пакет. Это число никогда не превышается. Однако меньше событий может быть доставлено, если другие события не доступны во время публикации. Если доступно меньше событий, чем указано в параметре, Сетка событий не будет задерживать события для создания пакета. Число должно быть в пределах от 1 до 5000.
• Предпочтительный размер пакета в килобайтах — целевой размер пакета в килобайтах. Как и в случае с максимальными событиями, размер пакета может быть меньше, если больше событий недоступно во время публикации. Пакет может быть больше предпочтительного размера, если размер одного события превышает значение этого параметра. Например, если предпочтительный размер составляет 4 КБ, а событие 10 КБ отправляется в сетку событий, событие 10 КБ по-прежнему поставляется в собственном пакете, а не удаляется.

Вы настраиваете пакетную доставку на основе подписки на события через портал, интерфейс командной строки (CLI), PowerShell или пакеты для разработки программного обеспечения (SDK).

Логика работы пакетной обработки

• Всё или ничего

  Сервис Event Grid работает по принципу "всё или ничего". Она не поддерживает частичное выполнение пакетной доставки. Подписчикам следует быть осторожными и запрашивать только столько событий на пакет, сколько они смогут обработать в течение 30 секунд.

• Оптимистичная пакетная обработка

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

• По умолчанию параметр установлен на ВЫКЛ.

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

• Значения по умолчанию

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

Портал Azure

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

Azure CLI (Интерфейс командной строки для Azure)

При создании подписки на события используйте следующие параметры:

• max-events-per-batch — максимальное число событий в пакете. Введите число от 1 до 5 000.
• preferred-batch-size-in-kilobytes — предпочтительный размер пакета в килобайтах. Введите число от 1 до 1024.

storageid=$(az storage account show --name <storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
endpoint=https://$sitename.azurewebsites.net/api/updates

az eventgrid event-subscription create \
  --resource-id $storageid \
  --name <event_subscription_name> \
  --endpoint $endpoint \
  --max-events-per-batch 1000 \
  --preferred-batch-size-in-kilobytes 512

Дополнительные сведения об использовании Azure CLI с Сеткой событий см. в разделе Перенаправление событий хранилища в конечную веб-точку с помощью Azure CLI.

Отложенная доставка

Когда конечная точка испытывает сбои доставки, Event Grid начинает откладывать доставку и повторяет попытки доставки событий в эту конечную точку. Например, если первые 10 событий, опубликованных в конечную точку, завершаются сбоем, Event Grid предполагает, что конечная точка испытывает проблемы и задерживает все последующие повторные попытки и новые доставки на некоторое время; в некоторых случаях до нескольких часов.

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

События недоставленных сообщений

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

• событие не доставлено в течение срока жизни;
• Число попыток доставки события превышает предельное значение.

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

Служба "Сетка событий" отправляет событие в расположение недоставленной буквы при попытке выполнить все попытки повторных попыток. Если Сетка событий получает код ответа 400 (ошибка запроса) или 413 (слишком большой запрос), она немедленно планирует отправку события в очередь недоставленных сообщений. Эти коды ответа указывают на то, что доставка события никогда не удается.

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

Существует 5-минутная задержка между последней попыткой доставки события и его отправкой в очередь недоставленных писем. Эта задержка уменьшает количество операций Blob-хранилища. Если место назначения недоставленных сообщений недоступно в течение четырех часов, событие удаляется.

Прежде чем задать расположение для dead-letter, необходимо создать учетную запись хранения с контейнером. При создании подписки на событие необходимо ввести конечную точку для этого контейнера. Конечная точка имеет следующий формат: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Возможно, вы захотите получать уведомления, когда событие отправляется в очередь непринятых сообщений. Чтобы использовать Event Grid для реагирования на недоставленные события, создайте подписку на события для хранилища dead-letter событий. Каждый раз, когда ваше хранилище больших двоичных объектов недоставленных сообщений получает недоставленное событие, служба "Сетка событий Azure" уведомляет вашего обработчика. Обработчик отвечает действиями, которыми вы хотите воспользоваться для урегулирования недоставленных событий. Пример настройки расположения недоставленных сообщений и политик повтора см. в разделе Недоставленные сообщения и политики повтора.

Форматы событий доставки

В этом разделе приведены примеры событий и событий, помещённых в очередь недоставленных сообщений, в различных форматах схемы доставки (схема Event Grid, схема CloudEvents 1.0 и пользовательская схема). Дополнительные сведения об этих форматах см. в статьях схемы сетки событий и облачных событий 1.0 .

Схема Сетки событий

Мероприятие

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/000000000-0000-0000-0000-00000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    }
}

Событие недоставленного сообщения

{
    "id": "93902694-901e-008f-6f95-7153a806873c",
    "eventTime": "2020-08-13T17:18:13.1647262Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "dataVersion": "",
    "metadataVersion": "1",
    "topic": "/subscriptions/0000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
    "subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",    
    "data": {
        "api": "PutBlob",
        "clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
        "requestId": "93902694-901e-008f-6f95-7153a8000000",
        "eTag": "0x8D83FACDC0C3402",
        "contentType": "text/plain",
        "contentLength": 0,
        "blobType": "BlockBlob",
        "url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
        "sequencer": "00000000000000000000000000015508000000000005101c",
        "storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
    },

    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T17:18:14.0265758Z",
    "lastDeliveryAttemptTime": "2020-08-13T17:18:14.0465788Z" 
}

Ниже приведены возможные значения lastDeliveryOutcome и их описание.

LastDeliveryOutcome: Испытательный срок

Event Grid помещает подписку на событие под наблюдение на определенный период времени, если доставка событий в этот пункт назначения начинается сбоем. Испытательный срок отличается для разных ошибок, возвращаемых целевой конечной точкой. Если подписка на события находится на испытательном сроке, события могут быть помещены в список недоставленных или удалены без попытки доставки, в зависимости от кода ошибки, который вызвал это состояние.

Схема CloudEvents 1.0

Мероприятие

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Событие недоставленного сообщения

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    },

    "deadletterreason": "MaxDeliveryAttemptsExceeded",
    "deliveryattempts": 1,
    "lastdeliveryoutcome": "NotFound",
    "publishtime": "2020-08-13T21:21:36.4018726Z",
}

Пользовательская схема

Мероприятие

{
    "prop1": "my property",
    "prop2": 5,
    "myEventType": "fooEventType"
}

Событие недоставленного сообщения

{
    "id": "8bc07e6f-0885-4729-90e4-7c3f052bd754",
    "eventTime": "2020-08-13T18:11:29.4121391Z",
    "eventType": "myEventType",
    "dataVersion": "1.0",
    "metadataVersion": "1",
    "topic": "/subscriptions/00000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.EventGrid/topics/myCustomSchemaTopic",
    "subject": "subjectDefault",
  
    "deadLetterReason": "MaxDeliveryAttemptsExceeded",
    "deliveryAttempts": 1,
    "lastDeliveryOutcome": "NotFound",
    "publishTime": "2020-08-13T18:11:29.4121391Z",
    "lastDeliveryAttemptTime": "2020-08-13T18:11:29.4277644Z",
  
    "data": {
        "prop1": "my property",
        "prop2": 5,
        "myEventType": "fooEventType"
    }
}

Состояние доставки сообщения

Сетка событий использует коды ответов HTTP для подтверждения получения событий.

Коды успешной доставки

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

• 200 OK (Запрос выполнен успешно)
• 201 Создано
• 202 — принято
• 203 — не заслуживающая доверия информация
• 204 Нет контента

Коды ошибок

Сетка событий считает все коды состояния за пределами диапазона 200-204 как сбои. Если происходит ошибка при доставке событий, Event Grid выполняет повторную попытку доставки. Некоторые коды сбоев имеют определенные политики повторных попыток, описанные в следующей таблице. Все остальные коды сбоев соответствуют стандартной экспоненциальной модели отката. Из-за высокой параллелизации архитектуры Сетки событий поведение повторных попыток является недетерминированным.

Пользовательские свойства доставки

При создании подписки на события можно добавить до 10 пользовательских заголовков HTTP для включения в доставленные события. Каждое значение заголовка не может превышать 4 096 (4 КБ). Эта функция позволяет задать пользовательские заголовки, необходимые для целевого адресата. Пользовательские заголовки можно задавать для событий, которые доставляются в следующие местоположения:

• Веб-перехватчики
• Разделы и очереди Azure Service Bus
• Центры событий Azure
• Подключения Relay Hybrid

Дополнительные сведения см. в разделе Пользовательские свойства доставки.

Связанный контент

• Сведения о том, как просмотреть состояние доставки событий, см. в статье Мониторинг доставки сообщений Event Grid.
• Чтобы настроить параметры доставки событий, см. в разделе Недоставленные сообщения и политики повтора.