Привет, Хабр! Представляю вам третью (заключительную) часть серии статей, посвященных оптимизации развертывания 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 показывает длительное время обработки запросов, вы можете проследить за показателями, приведенными ниже, чтобы понять, на что тратится время обработки запросов.
Метрика | Описание |
| Время ожидания запроса на удаленном клиенте, для продюсера, консьюмера и последователя реплики. Высокое значение может означать медленное сетевое соединение. Для запросов на выборку, если удаленное время велико, это может означать, что в ответе на выборку недостаточно данных. |
| Время ожидания запроса в очереди ответов для продюсера, консьюмера и последователя реплики. Высокое значение может означать, что сетевых потоков недостаточно. |
| Время, в течение которого запрос отправляется обратно клиенту, для продюсера, консьюмера и последователя реплики. Высокое значение может означать, что сетевых потоков недостаточно, либо процессор или сеть являются узким местом. |
| Размер очереди запросов. В идеале этот показатель должен быть близок к нулю. Скачки - это нормально, но постоянно переполненная очередь запросов не сможет обрабатывать входящие и исходящие запросы. |
| Суммарный размер очереди ответов. Если со временем этот показатель увеличивается, это может свидетельствовать о наличии проблем как на стороне отправителя, так и на стороне обработки запросов. |
| Средняя продолжительность простоя сетевых потоков. Меньшее значение означает, что используется больше ресурсов. Полезно использовать в паре с вышеуказанными метриками JMX, связанными с запросами. |
| Средняя продолжительность простоя потоков ввода-вывода. Полезно использовать в паре с вышеуказанными метриками JMX, связанными с запросами. |
| Частота выполнения выгрузки кэша страниц журнала Kafka и продолжительность выгрузки. Может использоваться для диагностики медленного диска или неправильно настроенного кэша страниц. Длительная выгрузка свидетельствует о низкой производительности хранилища. |
При проведении сравнительных тестов для продюсера необходимо убедиться, что код самого продюсера не вносит задержек. Отслеживайте время, проведенное продюсером в пользовательских процессах. Используя метрики io-ratio и io-wait-ratio, описанные ниже, время обработки пользователем - это доля времени, не приходящаяся ни на один из этих потоков, поэтому если время обработки в них мало, то время обработки пользователем может быть большим, и это приводит к тому, что единственный поток ввода-вывода продюсера остается занятым. Например, проверьте, не использует ли продюсер обратные вызовы (callbacks), которые вызываются при подтверждении сообщений и выполняются в потоке ввода-вывода.
Метрика | Описание |
| Доля времени, затраченного потоком ввода-вывода на выполнение операций ввода-вывода |
| Доля времени ожидания потока ввода-вывода |
Чтобы оценить общий уровень "здоровья" кластера, то есть работоспособность брокеров и репликацию партиций, следите за общим состоянием кластера в Control Center.
Если вы собираете JMX метрики, отслеживайте IsrShrinksPerSec и UnderReplicatedPartitions. Если эти значения нестабильны, и вы намеренно не завершаете работу брокеров плавно, то, скорее всего, брокеры мягко отказывают или между ними есть проблемы с подключением.
Метрика | Описание |
| Скорость, с которой сокращается ISR. ISR будет сокращаться, если брокер отключается, либо плавно, либо нет. |
| Всегда должно быть 0. Если он больше 0, то, скорее всего, брокер не справляется с репликацией. |
Кроме того, если целью вашего сервиса является низкая задержка, следите за пропускной способностью и задержкой потоков от одного "конца" к другому для каждой группы консьюмеров, консьюмера, топика или партиции.
Чтобы узнать, насколько клиентские приложения консьюмеров отстают в чтении файлов журнала, отследите отставание консьюмеров по группам консьюмеров и по каждому консьюмеру.
Если вы собираете метрики JMX, контролируйте records-lag-max. Эта метрика сравнивает смещение, которое консьюмер видел в последний раз, с самым последним смещением в журнале. Эта метрика важна для потребительских приложений реального времени, где консьюмер должен обрабатывать самые новые сообщения с минимальной задержкой, поэтому задержка должна быть небольшой.
Метрика | Описание |
| Максимальное отставание по количеству записей для каждой партиции в этом окне. Увеличение значения с течением времени - лучший признак того, что группа консьюмеров не успевает за продюсерами. |
Кроме того, необходимо следить за базовой операционной системой, поскольку здоровье операционной системы - это основа здоровья Kafka. Вот некоторые из компонентов, которые вы должны контролировать:
Использование памяти
Использование диска
Загрузка CPU
Открытие дескрипторов файлов
Дисковый ввод-вывод
Сетевой ввод-вывод
