Конфигурирование алертов prometheus или как мы настраивали алерты для бизнес-метрик

Привет! Я Сергей Житинский, CEO DevOps-компании «Git in Sky». В статье расскажу, как настроить мониторинг Apache NiFi  ^[1]и алерты при переполнении очереди по достижении 8000 FlowFiles.

Зачем вам читать эту статью? Переполнение очереди FlowFiles в Apache NiFi может привести к замедлению или остановке обработки данных, мониторинг позволит своевременно среагировать на проблемы с производительностью и выявить узкие места.

Статей о том, что такое Apache NiFi, довольно много: Раз ^[2], Два ^[3], Три ^[4].

Для начала опишу, как работает 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. Не путать с объемом очереди, так как один элемент может весить сколько угодно.

Так выглядит алерт:

На этом у меня все. Пишите комментарии, буду рад получить обратную связь .