Comments 2
Было такое что подрядчики часто просят настроить мониторит числа объектов в очереди (не только NiFi). Через неделю прилетает большое число объектов и срабатывает мониторинг. На вопрос что случилось подрядчики говорят, что у них все хорошо. В результате все приходит к тому, что сам факт объектов в очереди не интересен. Интересно разбирается ли очередь и как долго объекты в ней находятся. Например, метрика nifi_average_lineage_duration.
Кстати, видел такой вариант мониторинга активности. Делаем отправку копии данных через отдельный коннектор на некоторый выключенный процессор. В результате в очереди копятся объекты. Добавляем время expire на коннекторе. В результате пока в очереди на коннекторе есть объекты, то данные поступают. Такой вариант мне видеться костыльным, но забавным.
Добрый день!
Небольшой вопрос по бизнес-метрикам. В моем понимании, это метрики, которые показывают, насколько хорошо мы предоставляем ту или иную бизнес-услугу пользователю. С указанными бизнес-метриками (отслеживание статусов транзакций, скорость обработки транзакций, время нахождения в статусе X) соглашусь. Не очень понятен следующий момент: ваш бизнес-мониторинг состоит из одной метрики nifi_amount_items_queued? Или мониторятся все три указанные метрики?
Также не очень понятно, зачем нужно мониторить количество данных в очереди. Разве это значение всегда показывает аномальную ситуацию, на которую нужно срочно реагировать? Как пример - в очередь прилетело 9000 запросов, но они обработались за пару минут и не создали критичной очереди. В этом случае алерт сработает, хотя ничего страшного не случилось. Или другой пример - в очередь поместили 100 жирных запросов, каждый из которых обрабатываются сутки. За ними встали еще 1000 лёгких запросов. И они не смогут обработаться, пока не обработаются те 100. То есть время нахождения транзакций в очереди будет сильно большим. Похоже на сбой, хотя мониторинг его не обнаружил.
Конфигурирование алертов prometheus или как мы настраивали алерты для бизнес-метрик