Привет, Хабр! Представляю вам третью (заключительную) часть серии статей, посвященных оптимизации развертывания Kafka кластера (ссылка на первую и вторую части). Это перевод руководства от Confluent. Сегодняшняя статья посвящена сравнительному тестированию настроек и мониторингу Kafka кластера.

Сравнительное тестирование (бенчмаркинг) важно, потому что не существует универсальных рекомендаций по параметрам конфигурации, о которых шла речь в предыдущих статьях. Правильная конфигурация всегда зависит от сценария использования, аппаратного профиля каждого брокера (процессор, память, полоса пропускания и т. д.), других включенных функций, профиля данных и т. д. Если вы настраиваете Kafka не в соответствии с настройками по умолчанию, мы обычно рекомендуем проводить сравнительное тестирование. Независимо от целей вашего сервиса, вы должны понимать, каков профиль производительности кластера - это особенно важно, когда вы хотите оптимизировать пропускную способность или задержку. Ваши бенчмарк тесты также могут использоваться для расчетов при определении правильного количества партиций, размера кластера и количества процессов продюсеров и консьюмеров.

Начните тестирование с проверки вашей среды с параметрами конфигурации Kafka, установленными по умолчанию, и, пожалуйста, ознакомьтесь с тем, что такое параметры по умолчанию! Определите базовый профиль эффективности для выбранного продюсера. Сначала подготовьте условия для теста, устранив зависимости от всего, что находится "выше по течению" от продюсера. Вместо того чтобы получать данные из вышестоящих источников, модифицируйте свой продюсер таким образом, чтобы он сам генерировал имитационные данные с очень высокой скоростью, чтобы генерация данных не была узким местом. Если вы тестируете со включенной компрессией, обратите внимание на то, как генерируются имитационные данные. Иногда сгенерированные имитационные данные нереалистично заполняются всеми нулями. Это может привести к тому, что результаты сжатия будут лучше, чем в производстве. Убедитесь, что имитационные байты отражают производственные данные.

Запустите одного клиента продюсера на одном сервере. Кластер Kafka должен быть достаточно большим, чтобы он не был узким местом. Измерьте полученную пропускную способность с помощью доступных JMX-метрик для продюсера Kafka. Повторите сравнительный тест продюсера, увеличивая количество процессов продюсера на сервере в каждой итерации, чтобы определить количество процессов продюсера на сервер для достижения наивысшей пропускной способности. Аналогичным образом можно определить базовый профиль производительности для конкретного консьюмера. Запустите одного клиента-консьюмера на одном сервере. Повторите сравнительный тест консьюмера, увеличивая количество процессов консьюмера на сервере в каждой итерации, чтобы определить количество процессов консьюмера на сервер для достижения наивысшей пропускной способности.

Затем вы можете провести сравнительное тестирование для различных вариантов конфигурационных параметров, отражающих цели вашего сервиса. Сосредоточьтесь на параметрах конфигурации, рассмотренных в данной серии статей, и избегайте соблазна обнаружить и изменить другие параметры по сравнению с их значениями по умолчанию, не понимая, как именно они влияют на всю систему. Используя уже рассмотренные параметры, настраивайте параметры на каждой итерации, проводите тест, наблюдайте за результатами, снова настраивайте и так далее, пока не определите параметры, которые соответствуют вашим требованиям к пропускной способности и задержкам. Обратитесь к этой статье блога Confluent, когда будете оценивать количество партиций в своих бенчмарк-тестах.

Перед запуском в производство убедитесь, что вы создали надежную систему мониторинга всех брокеров, продюсеров, консьюмеров, топиков и любых других компонентов Kafka или Confluent, которые вы используете. Мониторинг состояния обеспечивает уверенность в том, что компоненты работают нормально: брокеры запущены, на каждом из них достаточно места на диске, каждое сообщение получено "из конца в конец" и т.д.

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

Confluent предлагает центр управления профессионального уровня Confluent Control Center для мониторинга состояния и производительности вашего кластера Kafka. В качестве альтернативы вы можете запускать процессы Kafka с настроенной переменной окружения JMX_PORT, чтобы открыть внутренние метрики JMX для инструментов JMX. Существует множество внутренних метрик Kafka, которые отображаются через JMX для получения информации о производительности кластера.

Когда вы введете в эксплуатацию мониторинг кластера Kafka, вы можете рассмотреть возможность установки оповещений, основанных на задачах вашего сервиса. Эти оповещения могут даже варьироваться от топика к топику. Например, один топик, обслуживающий приложение с требованиями к низкой задержке, может иметь разные уровни оповещения по сравнению с другим топиком, обслуживающим приложение с требованиями к высокой пропускной способности.

Сначала оцените нагрузку на кластер. На обзорной панели состояния системы в Control Center представлена сводка запросов продюсеров и запросов на выборку по всему кластеру.

Следующие метрики являются хорошей отправной точкой для оценки нагрузки на брокер.

Если вы хотите выявить узкие места в производительности, вам необходимо отслеживать показатели, которые показывают, на что тратится время обработки. Вам может потребоваться сопряжение нескольких метрик JMX, чтобы определить, где находится узкое место. Например, если метрика TotalTimeMs показывает длительное время обработки запросов, вы можете проследить за показателями, приведенными ниже, чтобы понять, на что тратится время обработки запросов.

При проведении сравнительных тестов для продюсера необходимо убедиться, что код самого продюсера не вносит задержек. Отслеживайте время, проведенное продюсером в пользовательских процессах. Используя метрики io-ratio и io-wait-ratio, описанные ниже, время обработки пользователем - это доля времени, не приходящаяся ни на один из этих потоков, поэтому если время обработки в них мало, то время обработки пользователем может быть большим, и это приводит к тому, что единственный поток ввода-вывода продюсера остается занятым. Например, проверьте, не использует ли продюсер обратные вызовы (callbacks), которые вызываются при подтверждении сообщений и выполняются в потоке ввода-вывода.

Чтобы оценить общий уровень "здоровья" кластера, то есть работоспособность брокеров и репликацию партиций, следите за общим состоянием кластера в Control Center.

Если вы собираете JMX метрики, отслеживайте IsrShrinksPerSec и UnderReplicatedPartitions. Если эти значения нестабильны, и вы намеренно не завершаете работу брокеров плавно, то, скорее всего, брокеры мягко отказывают или между ними есть проблемы с подключением.

Кроме того, если целью вашего сервиса является низкая задержка, следите за пропускной способностью и задержкой потоков от одного "конца" к другому для каждой группы консьюмеров, консьюмера, топика или партиции.

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

Если вы собираете метрики JMX, контролируйте records-lag-max. Эта метрика сравнивает смещение, которое консьюмер видел в последний раз, с самым последним смещением в журнале. Эта метрика важна для потребительских приложений реального времени, где консьюмер должен обрабатывать самые новые сообщения с минимальной задержкой, поэтому задержка должна быть небольшой.

Кроме того, необходимо следить за базовой операционной системой, поскольку здоровье операционной системы - это основа здоровья Kafka. Вот некоторые из компонентов, которые вы должны контролировать:

• Использование памяти

• Использование диска

• Загрузка CPU

• Открытие дескрипторов файлов

• Дисковый ввод-вывод

• Сетевой ввод-вывод