Диагностика сбоев в лазурной сетке событий?

Question

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

Поэтому я задаю вопрос относительно следующего сценария:

1. Наш кодпубликует события в домене.
2. События доставляются настроенному веб-хуку в подписке.
3. Это работает некоторое время.
4. Потребитель (которому принадлежитконечная точка веб-перехвата) жалуется, что он не получает некоторые события, но большинство проходит через него.
5. Мы просматриваем настроенную очередь недоставленных сообщений и обнаруживаем, что никаких событий нет.Прошло более суток, и, следовательно, все повторные попытки уже исчерпаны.
6. Следовательно, мы предполагаем, что все события доставляются, поскольку в метриках нет событий неудачной доставки.
7. Мы также делаемуверен, что мы действительно отправили эти таинственные события в сетку.
8. Но потребитель настаивает на проблеме и доказывает, что с его стороной все в порядке.
9. Теперь нам нужно выяснить,эти события поглощаются сеткой событий.

Как мне устранить неполадки в этом сценарии?

Answer 1

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

Для вашего сценария, основанного на событииДомены (все еще в общедоступном предварительном просмотре, см. пределы ) могут помочь API REST мониторинга Azure в просмотре всех метрик в конкретном вашем домене событий.

Действительныйметрики:

PublishSuccessCount,PublishFailCount,PublishSuccessLatencyInMs,MatchedEventCount,DeliveryAttemptFailCount,DeliverySuccessCount,DestinationProcessingDurationInMs,DroppedEventCount,DeadLetteredCount

В следующем примере приведен запрос REST GET для получения всех значений метрик в вашей области событий для определенного промежутка времени и интервала:

https://management.azure.com/subscriptions/{mySubId}/resourceGroups/{myRG}/providers/Microsoft.EventGrid/domains/{myDomain}/providers/Microsoft.Insights/metrics?api-version=2018-01-01&interval=PT1H&aggregation=count,total&timespan=2019-02-06T07:58:12Z/2019-02-07T08:58:12Z&metricnames=PublishSuccessCount,PublishFailCount,PublishSuccessLatencyInMs,MatchedEventCount,DeliveryAttemptFailCount,DeliverySuccessCount,DestinationProcessingDurationInMs,DroppedEventCount,DeadLetteredCount

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

Другой момент заключается в расширении модели событий для Одитинг части.Я рекомендую следующее:

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

2. Добавить подписку хранения для сообщений с недоставленными сообщениями и отправить их в тот же концентратор событий для потоковой передачи..

3. (необязательно) Добавьте параметры диагностики (некоторые показатели) хранилища недоставленных сообщений в тот же концентратор событий для потоковой передачи.Обратите внимание, что сообщение о недоставленном письме сбрасывается через 4 часа при попытке сохранить его в контейнере BLOB-объектов.Для этого неудачного процесса нет никаких сообщений журнала, только счетчик метрик.

Для стороны клиента , я рекомендую каждому подписчику создать сообщение журнала(aeg заголовки + сообщение о событии) для целей аудита и устранения неполадок.Он должен храниться в контейнере больших двоичных объектов или локально, а затем загружаться и т. Д. Дело в том, что эта ссылка может быть очень полезна для анализа потокового задания, чтобы быстро выяснить, в чем проблема.

Вдобавив к вашей модели событий, ваш издатель должен периодически (например, один раз в час) исследовать конечную точку домена событий, а также отправлять сообщение о событии исследования в тему исследования в целях тестирования.Подписка на событие для этой темы зонда настроит вариант рассылки сообщений.Обработчик веб-крюка подписчика всегда должен завершаться с ошибкой с кодом ошибки HttpStatusCode.BadRequest , например, без повторных попыток.Обратите внимание, что существует 300 секунд задержки, когда сообщение о недоставке будет сохранено в хранилище.Другими словами, после события зондирования + 5 минут сообщение о недоставке должно быть в конвейере потока.Этот сценарий проверки в вашей модели событий будет проверять функциональность AEG от издателя и точки доставки представления.

Описанное выше решение показано в следующем фрагменте экрана: