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

Привет всем читателям VC. Прошу строго не судить, это моя первая статья здесь.

Меня зовут Георгий, я системный инженер в компании Git in Sky.

Итак, нас попросили настроить мониторинг Apache NiFi и настроить алерты при переполнении очереди по достижении 8000 FlowFiles. Эти метрики относятся к бизнес-метрикам.

Статей о том, что такое Apache NiFi, довольно много: Раз, Два, Три. Как настроить сбор метрик в prometheus немного, но есть: Раз, Два.

Для начала нам необходимо понять, как работает nifi и какие именно метрики с какими параметрами отвечают за это.

1. Системный мониторинг (CPU/RAM/DISK/NET)

Функция: Мониторинг ресурсов сервера, таких как центральный процессор, оперативная память, дисковое пространство и сеть. Эти метрики важны для поддержания общей работоспособности системы.

Пример: Использование CPU, использование RAM, скорость чтения/записи на диск, пропускная способность сети.

Абстракция: Системный мониторинг абстрагирует ресурсы инфраструктуры, обеспечивая видимость и контроль за состоянием серверов и других компонентов системы.

2. Приложения healthcheck (доступность, ошибки)

Функция: Мониторинг состояния приложений, включая их доступность и наличие ошибок. Healthcheck позволяет убедиться, что приложения работают корректно и предоставляют ожидаемые услуги.

Пример: Проверка доступности веб-сервиса, отслеживание ошибок в логах приложения.

Абстракция: Healthcheck абстрагирует состояние приложений, обеспечивая контроль за их доступностью и корректной работой.

3. Связи (доступность зависимых сервисов)

Функция: Мониторинг доступности зависимых сервисов и их взаимодействия с основным приложением. Это важно для обеспечения устойчивости и производительности системы в целом.

Пример: Проверка доступности базы данных, API внешнего сервиса.

Абстракция: Мониторинг связей абстрагирует зависимости между сервисами, обеспечивая контроль за взаимодействием компонентов системы.

4. Бизнес метрики

Статусы транзакций (ok/failed/decline): Отслеживание успешных, неудачных и отклоненных транзакций для анализа и оптимизации бизнес-процессов.

Скорость транзакций: Измерение времени, необходимого для выполнения транзакций, для оценки производительности системы.

Время нахождения в статусе (step1, step2, step3): Отслеживание времени, которое транзакции проводят на каждом этапе обработки, для выявления узких мест и улучшения процессов.

Абстракция: Бизнес метрики абстрагируют ключевые показатели производительности и эффективности бизнес-процессов, обеспечивая контроль и оптимизацию операций.

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

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

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