Привет! Я Сергей Житинский, CEO DevOps-компании «Git in Sky». В статье расскажу, как настроить мониторинг Apache NiFi и алерты при переполнении очереди по достижении 8000 FlowFiles.
Зачем вам читать эту статью? Переполнение очереди FlowFiles в Apache NiFi может привести к замедлению или остановке обработки данных, мониторинг позволит своевременно среагировать на проблемы с производительностью и выявить узкие места.
Статей о том, что такое Apache NiFi, довольно много: Раз, Два, Три.
Для начала опишу, как работает NiFi и какие именно метрики с какими параметрами отвечают за это.
Мониторинг можно условно разделить на 4 части:
1. Системный мониторинг (CPU/RAM/DISK/NET)
-
Функция: Мониторинг ресурсов сервера, таких как центральный процессор, оперативная память, дисковое пространство и сеть. Эти метрики важны для поддержания общей работоспособности системы.
-
Пример: Использование CPU, использование RAM, скорость чтения/записи на диск, пропускная способность сети.
-
Абстракция: Системный мониторинг абстрагирует ресурсы инфраструктуры, обеспечивая видимость и контроль за состоянием серверов и других компонентов системы.
2. Приложения healthcheck (доступность, ошибки)
-
Функция: Мониторинг состояния приложений, включая их доступность и наличие ошибок. Healthcheck позволяет убедиться, что приложения работают корректно и предоставляют ожидаемые услуги.
-
Пример: Проверка доступности веб-сервиса, отслеживание ошибок в логах приложения.
-
Абстракция: Healthcheck абстрагирует состояние приложений, обеспечивая контроль за их доступностью и корректной работой.
3. Связи (доступность зависимых сервисов)
-
Функция: Мониторинг доступности зависимых сервисов и их взаимодействия с основным приложением. Это важно для обеспечения устойчивости и производительности системы в целом.
-
Пример: Проверка доступности базы данных, API внешнего сервиса.
-
Абстракция: Мониторинг связей абстрагирует зависимости между сервисами, обеспечивая контроль за взаимодействием компонентов системы.
4. Бизнес метрики
-
Статусы транзакций (ok/failed/decline): Отслеживание успешных, неудачных и отклоненных транзакций для анализа и оптимизации бизнес-процессов.
-
Скорость транзакций: Измерение времени, необходимого для выполнения транзакций, для оценки производительности системы.
-
Время нахождения в статусе (step1, step2, step3): Отслеживание времени, которое транзакции проводят на каждом этапе обработки, для выявления узких мест и улучшения процессов.
-
Абстракция: Бизнес метрики абстрагируют ключевые показатели производительности и эффективности бизнес-процессов, обеспечивая контроль и оптимизацию операций.
Принцип работы NiFi можно условно разделить на 3 элемента:
1. Потоки данных (FlowFiles)
-
Функция: FlowFiles являются контейнерами данных, передаваемыми между процессорами. Каждый FlowFile состоит из содержимого (данные) и атрибутов (метаданные). Атрибуты включают такие свойства, как имя файла, размер, тип данных и пользовательские атрибуты, добавленные процессорами.
-
Пример: FlowFile может представлять собой запись журнала, XML файл, JSON объект или любой другой тип данных, который передается и обрабатывается в потоке данных.
-
Абстракция: FlowFiles абстрагируют данные и метаданные, позволяя легко манипулировать и отслеживать данные на протяжении всего процесса обработки.
2. Потоки управления (Flow Controller)
-
Функция: Flow Controller управляет координацией и выполнением процессов внутри NiFi. Он контролирует создание, уничтожение и перемещение FlowFiles между процессорами, обеспечивая соблюдение порядка выполнения и соблюдение правил маршрутизации.
-
Пример: Flow Controller обеспечивает последовательное выполнение процессоров, управление зависимостями между процессорами и обработку ошибок, чтобы гарантировать надежность и устойчивость потоков данных.
-
Абстракция: Flow Controller абстрагирует управление потоком данных, позволяя пользователям сосредоточиться на проектировании логики обработки данных без необходимости беспокоиться о деталях выполнения и координации.
3. Соединения (Connections)
-
Функция: Соединения определяют, как FlowFiles передаются между процессорами. Они управляют очередями FlowFiles, которые ждут обработки следующими процессорами. Потоки файлов, обработанные без сбоев, формируют выполненную очередь (success queue), а сообщения с проблемами обработки передаются в очередь сбоев (failure queue). Существуют и другие типы соединений для различных сценариев обработки данных.
-
Пример: Соединение может направлять успешно обработанные FlowFiles в следующий процессор, тогда как неудачные FlowFiles будут направлены в процессор, занимающийся обработкой ошибок или повторными попытками.
-
Абстракция: Соединения абстрагируют маршрутизацию и управление очередями FlowFiles, обеспечивая гибкость и контроль над потоком данных между процессорами.
Итак, нам необходима метрика nifi_amount_items_queued, и если в prometheus сделать запрос этой метрики, то мы увидим большое количество данных со значениями 0
Если посмотреть в web интерфейс NiFi, то там мы увидим все 3 элемента, описанные выше: DataFlow
Потоки управления
Соединения
Да, если вы внимательно посмотрели на последнюю картинку, то там видно, что очереди у нас копятся именно в соединениях success и failure. Соответственно нам необходимо их как - то отлавливать в prometheus. Если сделать запрос по component_name, то данных будет снова очень много и они не все нам нужны.
Давайте сделаем запрос:
nifi_amount_items_queued{component_name!="",source_name!="",destination_name!=""} > 0
Тогда мы увидим интересующие нас метрики с нужными нам значениями:
alt text
Необходимые метрики у нас есть. Давайте нарисуем правило:
groups:
- name: ansible managed alert rules
rules:
- alert: NifiQueueOverflow
expr: nifi_amount_items_queued{source_name!="", destination_name!=""} > 8000 for: 1m labels:
severity: warning annotations:
description: "Queue overflow detected in component {{ $labels.component_name }} (ID: {{ $labels.component_id }}) between {{ $labels.source_name }} and {{ $labels.destination_name }} ({{ $value }} items)"
summary: "Queue Overflow in NiFi"
Это правило сработает, когда количество данных в очереди достигнет 8000 FlowFiles. Не путать с объемом очереди, так как один элемент может весить сколько угодно.
Так выглядит алерт:
На этом у меня все. Пишите комментарии, буду рад получить обратную связь 🙂.
Автор: gitinsky
