Что такое задачи отчетности, зачем они нужны и как с их помощью отслеживать события и системные метрики экземпляра NiFi-приложения, а также JVM. Обзор Reporting Tasks в Apache NiFi 2.0.
Задачи отчетности в Apache NiFi
Чтобы отслеживать события и метрики работающего экземпляра приложения Apache NiFi, этот фреймворк предоставляет специализированные инструменты, которые называются задачи отчетности (Reporting Tasks). Они выполняются в фоновом режиме и позволяют отправить во внешние системы информацию о состоянии, статистике и системных метриках. Дата-инженер добавляет и настраивает задачи отчетности, аналогично процессу для служб контроллера. В версии NiFi 2.0 присутствуют следующие задачи отчетности:
- AzureLogAnalyticsProvenanceReportingTask для публикации событий происхождения (Provenance) в рабочей области Azure Log Analytics;
- AzureLogAnalyticsReportingTask для отправки метрик JVM, а также метрик самого Apache NiFi в рабочую область Azure Log Analytics. Метрики NiFi можно настроить либо на глобальном уровне, либо на уровне группы процессов.
- ControllerStatusReportingTask для регистрации 5-минутной статистики, которая отображается на сводной странице NiFi для процессоров и подключений. Также эта задача отчетности регистрирует разницу между предыдущей итерацией и текущей итерацией. Статистика процессоров регистрируется с помощью регистратора org.apache.nifi.controller.ControllerStatusReportingTask.Processors, а статистика соединений регистрируется с помощью регистратора org.apache.nifi.controller.ControllerStatusReportingTask.Connections. При желании их можно настроить в конфигурации логирования NiFi для регистрации в разных файлах.
- MonitorDiskUsage – задача, которая проверяет объем доступного места для хранения для указанного каталога и предупреждает о превышении лимита, заданного через настраиваемый порог места для хранения. Предупреждающее уведомление выводится через сообщение лога и бюллетень системного уровня.
- MonitorMemory — проверяет объем кучи Java, доступный в JVM для определенного пула памяти виртуальной машины, выдавая предупреждение о превышении этого лимита.
- PrometheusReportingTask отправляет метрики в формате Prometheus, создавая конечную HTTP(S)-точку /metrics, которую можно использовать для внешнего мониторинга приложения. Задача отчетности сообщает набор метрики JVM и экземпляра NiFi. Однако, если базовый сервер Jetty, т. е. конечная точка Prometheus, не может быть запущен, например, когда два экземпляра PrometheusReportingTask запускаются на одном и том же порту, это может привести к задержке завершения работы NiFi, пока он ожидает очистки ресурсов сервера.
- ScriptedReportingTask предоставляет отчеты и информацию о состоянии скрипту, включая объекты ReportingContext, ComponentLog и VirtualMachineMetrics в качестве переменных (context, log и vmMetrics соответственно) для дальнейшей обработки. Контекст делает доступной различную информацию, такую как события, происхождение, бюллетени, службы контроллера, группы процессов, метрики JVM и пр.
- StandardGangliaReporter позволяет использовать для мониторинга метрик Ganglia — масштабируемую распределённую систему мониторинга кластеров параллельных и распределённых вычислений и облачных систем с иерархической структурой. С Ganglia можно отслеживать статистику и историю вычислений в реальном времени для каждого из наблюдаемых узлов. Эта задача отчетности передает в Ganglia наиболее важные метрики JVM и 5-минутную статистику NiFi: полученные и отправленные FlowFiles и байты, прочитанные и записанные байты, общую продолжительность задач, а также текущие значения для FlowFiles Queued, Bytes Queued и количества активных потоков.
Протокол S2S и его задачи отчетности
Отдельно следует сказать о задачах отчетности, связанных с протоколом Site-to-Site (S2S). При отправке данных из одного экземпляра NiFi в другой можно использовать множество различных протоколов, наиболее предпочтительным из которых является S2S. Он часто используется в VPN-соединениях. В NiFi этот протокол упрощает безопасную и эффективную передачу данных между разными узлами в одном экземпляре NiFi или приложении-продюсере на узлы в другом экземпляре NiFi или приложении-потребителе.
Как в любом клиент-серверном взаимодействии, экземпляр NiFi, который инициирует связь, называется экземпляром клиента Site-to-Site , а отвечающий на его запросы экземпляр NiFi является сервером Site-to-Site. Чтобы спроектировать движение потока данных и настроить каждый экземпляр, необходимо знать, какой экземпляр NiFi будет клиентом, а какой — сервером. В зависимости от направления потока данных можно реализовать push- или pull-взаимодействие:
- при push-взаимодействии клиент отправляет данные в группу удаленных процессов, а сервер получает их через входной порт;
- при pull-взаимодействии клиент получает данные из группы удаленных процессов, а сервер отправляет данные через выходной порт.
Подробнее о том, как работает этот протокол, можно прочитать здесь, а сейчас вернемся к задачам отчетности, связанным с ним. Таким задачами отчетности являются следующие:
- SiteToSiteBulletinReportingTask — задача отчетности по S2S-бюллетеням позволяет пользователю публиковать события бюллетеней с использованием протокола Site-to-Site. Она публикует события бюллетеня, сохраняя на каждый компонент до 5 бюллетеней и до 10 бюллетеней на уровне контроллера длительностью до 5 минут. Если эта задача отчетности запланирована слишком редко, некоторые бюллетени могут не отправляться.
- SiteToSiteMetricsReportingTask — задача отчетности о метриках протокола Site-to-Site позволяет пользователю публиковать метрики NiFi в том же или другом экземпляре приложения. Это обеспечивает большую мощность, поскольку позволяет пользователю использовать все различные процессоры, доступные в NiFi, для обработки или распространения этих данных. Для вывода данных доступно два формата. Первый — это формат Ambari, определенный в API Ambari Metrics Collector, который представляет собой JSON-документ с динамическими ключами. При использовании этого формата для преобразования данных можно использовать спецификацию Jolt, о которой мы писали здесь. Второй формат использует структуру записи NiFi, позволяя пользователю определять записывающее устройство и напрямую указать выходной формат и данные на основе входная схема JSON-документа с JVM-метриками.
- SiteToSiteProvenanceReportingTask — задача отчетности позволяет пользователю публиковать все события происхождения (Provenance) из экземпляра NiFi обратно в тот же или другой экземпляр, используя S2S-протокол. Это обеспечивает большую мощность, поскольку позволяет пользователю использовать все различные процессоры, доступные в NiFi, для обработки или распространения этих данных. По возможности рекомендуется отправлять данные Provenance в другой экземпляр NiFi, отличный от того, на котором выполняется эта задача отчетности, поскольку использование протокола Site To Site само по себе генерирует Provenance-события, создавая цикл. Однако, данные событий Provenance отправляются пакетами, по каждому из которых принимающий экземпляр NiFi должен генерировать только одно событие для каждого компонента. По умолчанию в пакет входит 1000 событий происхождения данных. Изначально при публикации в экземпляре NiFi данные Provenance отправляются в виде массива JSON, но можно использовать запись и напрямую указать выходной формат и данные, задав в Record Writer входную схему JSON-документа.
- SiteToSiteStatusReportingTask – задача отчетности о состоянии между узлами позволяет пользователю публиковать события состояния с использованием S2S-протокола. Регулярные выражения фильтра типа и имени компонента образуют объединение: в отчет будут включены только компоненты, соответствующие обоим регулярным выражениям. Однако все группы процессов рекурсивно ищут соответствующие компоненты, независимо от того, соответствует ли группа процессов фильтрам компонентов. Пользователь может определить Record Writer и напрямую указать выходной формат и данные в виде JSON-документа.
Узнайте больше про администрирование и использование Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
