Версия сайта для слабовидящих
Специально для обучения разработчиков распределенных приложений и дата-инженеров масштабных платформ аналитики больших данных на Apache Flink, рассмотрим наиболее важные системные показатели, а также инструменты мониторинга этих метрик.
Мониторинг Flink-приложений: особенности и метрики
В общем случае мониторинг приложений гарантирует, что ПО обрабатывает данные и выполняет запрошенные действия ожидаемым образом. Непрерывное отслеживание производительности и системных метрик приложения включает их идентификацию, измерение и сопоставление фактических значений с плановыми, а также инструменты изоляции аномалий и исправления ошибок. Мониторинг распределенных приложений осложняется тем, что задания могут выполняться с высокой степенью параллелизма на нескольких машинах, в разных средах на множестве уровней абстракции (виртуализация, Kubernetes и пр.). Flink-приложения также могут иметь разные режимы развертывания: для каждого задания или режим сеанса. Кроме того, задания Flink запускают произвольный пользовательский код с настраиваемой бизнес-логикой и огромными различиями в поведении приложений, которые могут повлиять на базовые ресурсы и выявить различные узкие места. Поэтому для стабильной работы масштабных платформ на базе Apache Flink мониторинг является незаменимым средством поддержки надежности.
Набор инструментов мониторинга крупномасштабных приложений достаточно широк, однако их практическое применение к Flink имеет ряд специфических нюансов:
- логирование пригодится для отладки отдельных сбоев, но не очень подходит для крупномасштабного мониторинга, поскольку приходится регистрировать слишком много данных, что затрудняет настройку оповещений.
- системные метрики и метрики кластера помогают понять, как ведет себя базовый кластер Flink, Kubernetes и пр., но не дают глубокого понимания на уровне приложения. Поэтому рекомендуется обогащать приложение пользовательскими метриками, отражающими его критические части и состояния, что пригодится при устранении неполадок.
- средства профилирования могут предоставить очень подробную информацию о приложении для выявления узких мест, блокировок потоков и перегрузок, устранения утечек памяти, проблем с сборщиком мусора и пр. Это пригодится для устранения неполадок и настройки производительности, но не очень подойдет для крупномасштабного мониторинга из-за накопления огромного объема данных, которые трудно использовать для оповещения до возникновения проблем.
Поэтому во Flink введены собственные метрики – объекты, которые связывают идентификатор с измерением. Они бывают 4-х типов:
- счетчик (counter) — для подсчета чего-либо, например, numRecordsIn. Текущее значение может быть увеличено или уменьшено с помощью простого или логарифмического инкремента inc()/inc(long n) или декремента dec()/dec(long n). Можно создать и зарегистрировать счетчик, вызвав метод counter(String name) в MetricGroup.
- датчик (Gauge) возвращает значение любого типа по запросу, например, время безотказной работы. Чтобы использовать Gauge, надо сначала создать класс, реализующий интерфейс apache.flink.metrics.Gauge. Можно зарегистрировать Gauge, вызвав метод gauge(String name, Gauge gauge) в MetricGroup.
- гистограмма (histogram) измеряет статистические распределения, например распределение задержки, и может возвращать процентили. Зарегистрировать гистограмму можно, вызвав метод histogram(String name, Histogram histogram) в MetricGroup. Flink не предоставляет реализацию гистограммы по умолчанию, но предлагает оболочку, которая позволяет использовать гистограммы Codahale/DropWizard. Чтобы использовать эту оболочку, следует добавить зависимость в пользовательский файл pom.xml:
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-metrics-dropwizard</artifactId>
<version>1.15.0</version>
</dependency>
- измеритель скорости (meter) измеряет среднюю пропускную способность, например, numRecordsInPerSecond. Возникновение одного события можно зарегистрировать с помощью метода markEvent(), а нескольких событий одновременно — с помощью метода markEvent(long n), вызвав их в MetricGroup.
Каждая метрика привязана к определенному контексту в среде выполнения Flink, где область становится частью идентификатора метрики в виде <system scope> [+ <user scope>] + <metric name>. Существуют системные области для метрик в JobManager (JM), JM+job, TaskManager (TM), TM+job, задача и оператор. Разработчик может точно настроить форматы областей, чтобы адаптировать идентификаторы метрик к своим потребностям.
Потоковая обработка данных с помощью Apache Flink
Код курса
FLINK
Ближайшая дата курса
1 августа, 2024
Продолжительность
16 ак.часов
Стоимость обучения
48 000 руб.
Метрики Flink можно экспортировать с помощью MetricReporter, REST API или веб-интерфейса. Однако, Flink не является полноценной системой метрик и не пытается предоставить подходящую панель инструментов для мониторинга. Для эпизодических проверок в ходе отладки можно использовать пользовательский интерфейс, но в нем не хватает функциональных возможностей полноценной системы показателей и панели инструментов. Поэтому серьезный мониторинг приложений проходит через генераторы отчетов о метриках, которые записывают значения метрик во внешнюю систему. Обычно для Flink используются Prometheus, Datadoc, Ganglia, InfluxDB и прочие подобные системы. Также можно написать собственное средство монитринга, если возможностей готовых инструментов недостаточно. Какие метрики рекомендуется отслеживать для постоянного мониторинга крупномасштабных Flink-приложений, настройки предупреждений или устранения неполадок. Мы рассмотрим далее.
Метрики непрерывного мониторинга: состояние и пропускная способность
Одним из самых важных показателей работы Flink-приложения является его состояние, которое отслеживается следующими метриками:
- время безотказной работы (uptime);
- количество перезапусков (numRestarts);
- время восстановления после перезапуска (restartingTime).
В частности, если время перезапуска велико и наблюдается критическая задержка задания, можно настроить оповещения об этом, чтобы исправить ситуацию до того, это негативно отразится на бизнесе. Всякий раз, когда происходит сбой, и инициируется перезапуск, отказоустойчивые приложения Flink перезапускают задание с последней контрольной точки или точки сохранения. В этих случаях полезно убедиться, что не нужно возвращаться слишком далеко назад и повторно обрабатывать большое количество данных, поскольку это фактически увеличит время простоя задания. Для этого можно отслеживать различные общие метрики контрольных точек, например, numberOfCompletedCheckpoints, numberOfFailedCheckpoints, numberOfInProgressCheckpoints. Имеет смысл также заблаговременно отслеживать сбои контрольных точек для заданий, которые перезапускаются после предварительно определенного количества неудачных попыток контрольной точки. Оповещения можно настроить на каком-то пороге количества неудачных контрольных точек или на длительности последней успешной точки.
Однако, во Flink отсутствует непосредственная метрика «время последней пройденной контрольной точки» не существует. Можно извлечь это значение из последнего увеличения numberOfCompletedCheckpoints, получить его из REST API или рассчитать на основе частоты контрольных точек и настроить оповещение о нескольких последовательных сбоях контрольных точек.
Говоря про контрольные точки, отметим, что значение параметра lastCheckpointDuration должно быть меньше времени ожидания контрольной точки, иначе checkpoint завершится ошибкой. Можно настроить оповещения об этом на случай, если продолжительность будет увеличиваться. Но на случай ложных срабатываний вместо этого лучше оповещать о фактических сбоях контрольной точки. Метрику lastCheckpointSize можно использовать для оценки размера текущего состояния. При этом в Apache Flink 1.15 добавлена новая метрика lastCheckpointFullSize, которая предоставляет полный размер контрольной точки, включая файлы, совместно используемые с предыдущими контрольными точками, а не просто количество байтов в добавочной контрольной точке. Также для устранения сбоев контрольных точек пригодится метрика checkpointAlignmentTime — время между получением первого и последнего барьера контрольной точки. Она отслеживает время в наносекундах, которое потребовалось для завершения последнего выравнивания барьера, или сколько времени заняло текущее выравнивание.
В заключение отметим, что мониторинг производительности должен сопровождаться измерениями пропускной способности. Для этого Flink предлагает метрики numRecords(In|Out)PerSecond и numRecords(In|Out) для каждой подзадачи. Хотя они доступны для всех задач в задании, из-за обратного давления вверх по конвейеру Flink, обычно достаточно отслеживать пропускную способность на выходе источников и настраивать оповещения для этого. Некоторые улучшение, предлагаемые для следующих релизов, позволяют источникам и приемникам определять значимые метрики для своих входов и выходов. Отдельные источники и приемники данных уже используют это для предоставления входных и выходных метрик, но в текущую версию фреймворка это еще не все внедрено.
В следующий раз мы продолжим разговор про мониторинг системных метрик Flink-приложений и рассмотрим, как отслеживать задержку обработки данных. А про мониторинг системных метрик JVM и RocksDB читайте здесь.
Узнайте больше про использование возможностей Apache Flink для потоковой обработки событий в распределенных приложениях аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
