Где хранятся сообщения о событиях триггера BLOB-объектов Azure Event Grid и как их очистить?

Question

Простите, если моя терминология немного не в порядке; Я новичок в этом.

Я создал подписку Azure Event Grid, которая запускает событие всякий раз, когда я загружаю файл в хранилище BLOB-объектов. У меня есть функция Azure, которая отвечает на это событие. Наконец-то у меня все заработало, но у меня есть несколько оставшихся сообщений от предыдущих (плохих) загрузок, которые периодически терпят неудачу (как видно из окна «Журналы» на портале Azure для связанной функции Azure). Как будто они где-то хранятся в очереди и периодически повторяются, хотя я не уверен, так ли это работает.

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

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

Answer 1

В дополнение к ответу @ JoshCarlisle и более ясной доставке сообщений Сетка событий и повторите документ:

Мертвые буквы включают особый случай в логике политики повторных попыток. В случае если «мертвая надпись» имеет значение при включении и абоненту не удалось выполнить команду HttpStatusCode.BadRequest , Сетка событий остановит процесс повторной попытки, и событие будет отправлено мертвому пользователю. конечная точка письма. Этот код ошибки указывает, что доставка никогда не будет успешной.

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

"deadLetterReason": "UndeliverableDueToHttpBadRequest",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "BadRequest",
"lastHttpStatusCode": 400,

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

HttpStatusCode.ServiceUnavailable
HttpStatusCode.InternalServerError
HttpStatusCode.RequestTimeout
HttpStatusCode.NotFound
HttpStatusCode.Conflict
HttpStatusCode.Forbidden
HttpStatusCode.Unauthorized
HttpStatusCode.NotImplemented
HttpStatusCode.Gone

Пример некоторых свойств недоставленных букв, когда HttpStatusCode.RequestTimeout :

"deadLetterReason":"MaxDeliveryAttemptsExceeded",
"deliveryAttempts":3,
"lastDeliveryOutcome":"TimedOut",
"lastHttpStatusCode":408,

Теперь вы можете увидеть два приведенных выше случая различий, описанных в свойстве deadLetterReason , например " UndeliverableDueToHttpBadRequest " vs " MaxDeliveryAttemptsExceeded "

Еще одна вещь:

• При включении недоставленных букв Сетка событий НЕ доставит сообщение о недоставленных письмах в конечную точку мертвых букв сразу, но через ~ 300 секунд. Я надеюсь, что это ошибка, и она скоро будет исправлена. Практически, если подписчику не удалось, например, HttpStatusCode.BadRequest , мы не можем ждать в течение 5 минут событие из хранилища контейнера, это должно быть событие, управляемое близко к реальному времени.

Answer 2

Сетка событий автоматически повторит попытку доставки сообщения, если при попытке доставки будет получено что-либо, кроме 200 или 202 (ОК / Принят). По умолчанию он повторяет попытку в течение 24 часов и использует экспоненциальную резервную копию, которая добавляет дополнительное время между каждым запросом, пока он не сдается. То, что вы видите, - это процесс по умолчанию. (Вы также можете настроить обработку недоставленных писем с помощью учетной записи хранения, чтобы недоставленные сообщения хранились где-то в случае сбоя).

Вероятно, вам нужна политика повторных попыток, которую вы можете создать при создании подписки. Уверен, что вы можете установить максимальное количество попыток доставки, равное 1, чтобы оно не повторялось (и без поддержки мертвых писем сообщение по существу было бы отброшено). Более подробную информацию об этом можно найти на https://docs.microsoft.com/en-us/azure/event-grid/manage-event-delivery#set-retry-policy

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