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

У меня есть функция Azure (v2), которая отслеживает контейнер больших двоичных объектов и запускает новые большие двоичные объекты. Функция работала нормально, пока неожиданно не остановилась. С тех пор мы диагностировали проблему как результат того, что журналы больше не записываются (см. Вопрос на Форумы MS).

Насколько я понимаю, функция Azure отслеживает большие двоичные объекты напрямую до тех пор, пока в контейнере не будет более 10 тысяч больших двоичных объектов (см. документ). Так было с моей функцией - у меня было более 10 тыс. Блобов, поэтому журналы отслеживались. С тех пор я удалил большую часть своих BLOB-объектов, оставив только несколько сотен в каждом контейнере, включая те, которые находятся в контейнере $ log (пара тысяч среди всех контейнеров). Моя функция по-прежнему не запускается для новых BLOB-объектов, что указывает на то, что журналы все еще отслеживаются (которые работают некорректно).

У меня вопрос: как среда выполнения функции решает опрашивать капли напрямую или использовать журналы? И как мне заставить среду выполнения прекратить мониторинг файлов журналов?


azure azure-functions azure-functions-runtime
person brudert    schedule 30.11.2018    source источник
comment
Я рекомендую использовать для вашего решения модель Pub / Sub событий Azure Event Grid. Это модель событий Push по сравнению с функцией BlobTrigger, такой как модель Pull / Poll-Push.   -  person Roman Kiss    schedule 01.12.2018
comment
Спасибо. Да, Event Grid неоднократно рекомендовали. Я начинаю задаваться вопросом, полезен ли триггер blob для чего-то большего, чем POC?   -  person brudert    schedule 03.12.2018

Ответы (1)


arrow_upward
0
arrow_downward

Мой опыт показывает, что при больших объемах триггеры blob могут сработать или пропустить. Они могут не уловить каждое событие. Триггеры очереди очень надежны. Мы используем их для обработки 50К больших двоичных объектов в день. Если это критично для бизнеса, я бы рекомендовал использовать архитектуру очередь + большие двоичные объекты. Статья из MS, на которую вы тоже ссылались, теперь подталкивает людей в том же направлении.

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

Если вам требуется более быстрая или более надежная обработка большого двоичного объекта, рассмотрите возможность создания сообщения очереди при создании большого двоичного объекта. Затем используйте триггер очереди вместо триггера большого двоичного объекта для обработки большого двоичного объекта. Другой вариант - использовать сетку событий; см. руководство Автоматизация изменения размера загруженных изображений с помощью сетки событий.

Я не использовал Event Grid, но это кажется излишним? Для архитектуры очередь + большой двоичный объект мы будем следовать проверке претензий шаблон. Короче говоря, все, что запускает запись нового большого двоичного объекта, также должно записывать сообщение в очередь. Сообщение может быть URL-адресом большого двоичного объекта. Затем используйте функцию, запускающуюся по очереди, для отслеживания очереди, получения нового сообщения очереди с URL-адресом большого двоичного объекта и выполнения действий с ним. Триггер очереди не пропустит событие. Каждый blob будет обработан.

person Troy Witthoeft    schedule 30.12.2019