Метрики приложений Kafka Streams и средства их мониторинга

Как использовать один и тот же топик Kafka для источника и назначения данных, обеспечивая высокую пропускную способность и низкую задержку приложений Kafka Streams. А также рассмотрим, какие встроенные метрики приложений есть у Kafka Streams, как добавить свои собственные и с помощью каких инструментов их отслеживать в реальном времени.

Топики и потоки

Apache Kafka — это не просто распределенная платформа потоковой передачи событий, а целая экосистема. Одним из важных компонентов этой экосистемы является Kafka Streams – библиотека, которая позволяет разрабатывать мощные приложения потоковой обработки данных, хранящихся в топиках Apache Kafka. Kafka Streams также обеспечивает потоковую обработку в реальном времени поверх клиента stateful-потребителя. Эта библиотека значительно упрощает обработку потоков из топиков, обеспечивая параллелизм, распределенную координацию, отказоустойчивость и масштабируемость. Kafka Streams работает с сообщениями как с неограниченным, непрерывным потоком записей в реальном времени, взаимодействуя с кластером и используя хранилища состояний для хранения и запроса данных из топиков.

Обычно исходные и обработанные данные в Kafka хранятся в разных топиках. Использование одного и того же топика для входных и выходных данных допустимо, если для одного и того же ключа, например, идентификатора выполнения, есть только один процесс, который может его записать. А предупреждение Detected out-of-order KTable update for execution at offset …, partition … оповещает о наличии более одного процесса для одного и того же ключа, что может привести к непредвиденному поведению, например, перезаписи предыдущих значений. В этом случае параллельный процесс может записать данные в топик с тем же ключом, перезаписав предыдущее значение, что означает фактическую потерю данных. Поэтому необходимо определить только одного записи для ключа в один момент времени. Для этого потребуется разработать пользовательский соединитель (joiner) из-за отсутствия готового в Kafka Streams.

Прежде всего, необходимо создать промежуточное хранилище, которое сохранит последнее состояние выполнения, и написать пользовательскую функцию соединения потока выполнения с потоком результатов задач. Далее следует получить последнее значение из состояния, добавить результат задачи и выдать новое состояние, которое будет сохранено в промежуточном хранилище и окончательном топике. Это гарантирует, что состояние выполнения всегда будет последней версией, независимо от количества результатов параллельных задач.

Таким образом, чтобы отладить приложение Kafka Streams необходимо постоянно мониторить показатели его работы. Поскольку эти приложения потоковой обработки данных используются в высоконагруженных и бизнес-критичных системах, очень отслеживать их показатели, чтобы заблаговременно предупредить сбой.  Что это за метрики и как их отслеживать, мы рассмотрим далее.

Ключевые метрики приложений Kafka Streams

С точки зрения инженерной надежности, ключевыми метриками приложений потоковой обработки данных считаются следующие:

• задержка — время, необходимое для обслуживания запроса, за которое запись пройдет путь от источника к приемнику данных;
• трафик — количество запросов в секунду или количество записей, обработанных в конвейере данных;
• ошибки — частота неудачных запросов;
• насыщение – приближение к программно-аппаратным пределам, что снижает производительность системы, например, загрузка ЦП, потребление памяти, остаток свободного места на диске.

Библиотека Kafka Streams сообщает о различных метриках через JMX, что можно настроить для создания отчетов о статистике с помощью дополнительных подключаемых генераторов статистических данных с помощью параметра конфигурации metrics.reporters. Самый простой способ просмотреть доступные метрики — использовать такие инструменты, как JConsole, которые позволяют просматривать JMX MBeans.

Доступ ко всему реестру метрик экземпляра потокового приложения можно получить только для чтения с помощью метода KafkaStreams#metrics(). Реестр метрик будет содержать все доступные метрики. По умолчанию библиотека имеет метрики с тремя уровнями записи: info, debug и trace. На уровне отладки регистрируется большинство метрик, а на уровне info — только некоторые из них. Уровень трассировки записывает все возможные метрики. Указать, какие метрики надо собирать можно, используя параметр конфигурации metrics.recording.level.

Встроенные метрики приложения Kafka Streams делятся на следующие категории:

• метрики клиента;
• метрики потока;
• метрики задач;
• метрики узла обработчика в графе задания;
• метрики состояний для stateful-приложений;
• метрики встроенной key-value базы данных RocksDB, которая используется для сохранения состояний;
• метрики кэша записей.

Помимо встроенных метрик разработчики приложений Kafka Streams, использующие низкоуровневый API процессора, могут добавлять дополнительные показатели, которые им надо отслеживать. Метод ProcessorContext#metrics() предоставляет дескриптор объекта StreamMetrics, который можно использовать для добавления показателей задержки и пропускной способности с помощью StreamMetrics#addLatencyRateTotalSensor() и StreamMetrics#addRateTotalSensor(). А добавить любой другой тип метрики можно с помощью метода StreamMetrics#addSensor().

В заключение перечислим средства мониторинга, которые позволяют отслеживать встроенные и пользовательские метрики приложений потоковой обработки данных: Confluent Control Centre, Yahoo Kafka Manager, LinkedIn Burrow, KafDrop, Kafka Tool, AppDynamics, Datadog, Prometheus и Grafana. Подробно про эти и другие инструменты мониторинга мы писали здесь.

Освойте администрирование и эксплуатацию Apache Kafka и Flink для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Администрирование кластера Kafka
• Apache Kafka для инженеров данных
• Администрирование Arenadata Streaming Kafka

Источники

1. https://medium.com/@kestra-io/techniques-you-should-know-as-a-kafka-streams-developer-32442ac39925
2. https://medium.com/@yashwant.deshmukh23/kafka-real-time-streaming-application-monitoring-and-alerting-daa4a8796c61
3. https://docs.confluent.io/platform/current/streams/monitoring.html
4. https://www.baeldung.com/java-kafka-streams-vs-kafka-consumer