Отмена подписок на события в тематических разделах пространств имен в Azure Event Grid

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

Ниже приведены несколько сценариев, в которых будет происходить недоставленная буква.

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

События мертвых писем хранятся в Azure Blob Storage в формате JSON CloudEvents, как в режимах структурированного, так и двоичного содержимого.

Случаи использования

Ниже приведены несколько случаев использования, в которых вы можете использовать механизм обработки "мёртвых" писем в ваших приложениях.

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

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

Формат, используемый при хранении событий недоставленных букв, — это формат JSON CloudEvents. Недоставленная буква сохраняет схему и формат события. Однако, помимо исходного опубликованного события, дополнительные сведения о метаданных сохраняются с событием недоставленной буквы.

brokerProperties: метаданные, описывающие условие ошибки, которое привело к тому, что событие будет недоставлено. Эта информация всегда присутствует. Эти метаданные описаны с помощью объекта, имя ключа которого равно brokerProperties.
- deadletterreason - Причина, по которой событие было отправлено в мертвую очередь.
- deliveryattempts — Количество попыток доставки до того, как событие было перемещено в очередь мёртвых писем.
- deliveryresult — Последний результат последней попытки службы доставить событие.
- publishutc — Время в формате UTC, в течение которого событие сохранялось и принято (например, HTTP 200 ОК) сеткой событий.
- deliveryattemptutc — время UTC последней попытки доставки.
customDeliveryProperties — Заголовки (настраиваемые свойства push-доставки), настроенные в подписке на события и включаемые во все исходящие запросы отправки HTTP. Одно или несколько этих настраиваемых свойств могут присутствовать в сохраненном dead-letter JSON. Пользовательские свойства, определенные как секреты, не хранятся. Эти метаданные описаны с помощью отдельного объекта, имя ключа которого — customDeliveryProperties. Имена ключей свойств внутри этого объекта и их значения точно совпадают с именами ключей, заданными в подписке на события. Приведем пример:
```
Custom-Header-1: value1
Custom-Header-2: 32
```
Они сохраняются в объекте BLOB с использованием следующего объекта:
```
"customDeliveryProperties" : {
    "custom-header-1": "value1",
    "custom-header-2": "34"
}
```
Зафиксированное событие, помеченное как недоставка, JSON будет следующим:
```
{
    "event": {
        "specversion": "1.0",
        "type": "com.example.someevent",
        "source": "/mycontext",
        "id": "A234-1234-1234",
        "time": "2018-04-05T17:31:00Z",
        "comexampleextension1": "value",
        "comexampleothervalue": 5,
        "datacontenttype": "application/json",
        "data": {
            // Event's objects/properties
        }
    },
    "customDeliveryProperties": {
        "custom-header-1": "value1",
        "custom-header-2": "34"
    },
    "deadletterProperties": {
        "deadletterreason": "Undeliverable due to client error",
        "deliveryattempts": 3,
        "deliveryresult": "Unauthorized",
        "publishutc": "2023-06-19T23:28:08.3063899Z",
        "deliveryattemptutc": "2023-06-09T23:28:08.3220145Z"
    }
}
```

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

События, опубликованные с помощью структурированного режима CloudEvents

С событием, опубликованным в структурированном режиме CloudEvents:

POST / HTTP/1.1
HOST jfgnspsc2.eastus-1.eventgrid.azure.net/topics/mytopic1
content-type: application/cloudevents+json

{
    "specversion": "1.0",
    "type": "com.example.someevent",
    "source": "/mycontext",
    "id": "A234-1234-1234",
    "time": "2018-04-05T17:31:00Z",
    "comexampleextension1": "value",
    "comexampleothervalue": 5,
    "datacontenttype": "application/json",
    "data": {
        // json event object goes here        
    }
}

Следующие настраиваемые свойства доставки настроены в подписке на push-событие.

Custom-Header-1: value1
Custom-Header-1: 34

Когда событие отправлено в мертвую очередь, в Хранилище BLOB-объектов Azure создается BLOB-объект со следующим содержимым в формате JSON:

{
    "specversion": "1.0",
    "type": "com.example.someevent",
    "source": "/mycontext",
    "id": "A234-1234-1234",
    "time": "2018-04-05T17:31:00Z",
    "comexampleextension1": "value",
    "comexampleothervalue": 5,
    "datacontenttype": "application/json",
    "data": {
        // Event's objects/properties
    },
    "customDeliveryProperties": {
        "custom-header-1": "value1",
        "custom-header-2": "34"
    },
    "deadletterProperties": {
        "deadletterreason": "Undeliverable due to client error",
        "deliveryattempts": 3,
        "deliveryresult": "Unauthorized",
        "publishutc": "2023-06-19T23:28:08.3063899Z",
        "deliveryattemptutc": "2023-06-09T23:28:08.3220145Z"
    }
}

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

При публикации события в двоичном режиме CloudEvents:

POST / HTTP/1.1
HOST jfgnspsc2.eastus-1.eventgrid.azure.net/topics/mytopic1
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/vnd.apache.thrift.binary

<raw binary data according to encoding specs for media type application/vnd.apache.thrift.binary>

Следующие настраиваемые свойства доставки, указанные в подписке на push-событие.

Custom-Header-1: value1
Custom-Header-1: 34

Объект BLOB, созданный в Хранилище BLOB Azure, представлен в следующем формате JSON (так же, как и в структурированном режиме). В этом примере показано использование атрибута контекста data_base64, который используется, когда content-type или datacontenttype HTTP ссылаются на двоичный тип носителя. content-type Если содержимое JSON-формата (datacontenttype должно иметь формат */json или */*+json), data используется вместо data_base64.

{
    "event": {
        "specversion": "1.0",
        "type": "com.example.someevent",
        "source": "/mycontext",
        "id": "A234-1234-1234",
        "time": "2018-04-05T17:31:00Z",
        "comexampleextension1": "value",
        "comexampleothervalue": 5,
        "datacontenttype": "application/vnd.apache.thrift.binary",
        "data_base64": "...base64 - encoded of binary data encoded according to application / vnd.apache.thrift.binary specs..."
    },
    "customDeliveryProperties": {
        "Custom-Header-1": "value1",
        "Custom-Header-2": "34"
    },
    "deadletterProperties": {
        "deadletterreason": "Undeliverable due to client error",
        "deliveryattempts": 3,
        "deliveryresult": "Unauthorized",
        "publishutc": "2023-06-19T23:28:08.3063899Z",
        "deliveryattemptutc": "2023-06-09T23:28:08.3220145Z"
    }
}

Имя BLOB-объекта и расположение папки

Блоб — это файл JSON, имя которого является глобальным уникальным идентификатором (GUID). Например, 480b2295-0c38-40d0-b25a-f34b30aac1a9.json. Одно или несколько событий могут содержаться в одном блобе.

Структура папок выглядит следующим образом: <container_name>/<namespace_name>/<topic_name>/<event_subscription_name>/<year>/<month>/<day>/<UTC_hour> Например: /<mycontainer/mynamespace/mytopic/myeventsubscription/2023/9/23/2/480b2295-0c38-40d0-b25a-f34b30aac1a9.json.

Логика повторных попыток недоставки

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

10 секунд
1 минута
5 мин

После первых 5 минут служба продолжает попытки повторного подключения каждые 5 минут до достижения максимального периода попыток. Максимальный период повторных попыток составляет 2 дня, и он настраивается в свойстве deliveryRetryPeriodInDays подписок событий в подписке на события, какое из условий будет выполнено первым. Если не удается сохранить событие в blob-хранилище по завершении максимального числа повторных попыток, событие отбрасывается и сообщается как неудавшееся событие из мертвой очереди.

Если логика повторных попыток доставки недоставленного сообщения начинается до того, как завершится настроенное время хранения событий для подписки, а оставшееся время жизни события меньше заданного периода повторных попыток (например, осталось всего 4 часа, и для события настроено 2 дня, настроенных как deliverRetryPeriod для недоставленного сообщения), брокер сохраняет событие для учета логики повторных попыток до максимального настроенного периода повторных попыток доставки недоставленного сообщения.

Настройка недоставленных букв

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

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

Использование шаблона Resource Manager

Вот пример JSON фрагмента шаблона диспетчера ресурсов. Вы также можете использовать системно назначенное управляемое удостоверение (SystemAssigned).

{
    "deadLetterDestinationWithResourceIdentity": {
    "deliveryRetryPeriodInDays": 2,
    "endpointType": "StorageBlob",
    "StorageBlob": {
        "blobContainerName": "data",
        "resourceId": "/subscriptions/0000000000-0000-0000-0000-000000000000/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"
    },
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentity": "/subscriptions/0000000000-0000-0000-0000-000000000000/resourceGroups/myresourcegroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myusermsi"
		}
	}
}

Использование портала Azure

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

Снимок экрана: страница

Для существующей подписки:

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

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

Общие сведения о службе "Сетка событий" см. в разделе Общие сведения о службе "Сетка событий Azure".
Чтобы приступить к работе с тематическими разделами пространства имен, ознакомьтесь с публикацией событий с использованием тем пространств имен.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2023-11-15