Эффективные стратегии мониторинга и оповещения о состоянии Kafka

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

Хороший мониторинг Kafka начинается с небольшого набора вопросов о работоспособности: могут ли брокеры обслуживать запросы, могут ли разделы выбирать лидеров, догнали ли реплики, обрабатывают ли потребители достаточно быстро, и не заканчиваются ли в кластере ресурсы ЦП, памяти, сети или диска? Приведенные ниже метрики полезны, потому что они соотносятся с этими вопросами.

Почему мониторинг Kafka критически важен

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

• Задержка данных: Высокое отставание потребителей может указывать на то, что потребители не успевают за скоростью продюсеров, что приводит к устареванию данных и влияет на downstream-приложения.
• Использование ресурсов: Недостаток ЦП, памяти или дискового пространства на брокерах может привести к снижению производительности, отсутствию реакции или даже к сбоям брокеров.
• Дисбаланс разделов: Неравномерное распределение разделов между брокерами может привести к перегрузке одних брокеров и недоиспользованию других, что влияет на пропускную способность и доступность.
• Доступность брокеров: Сбои брокеров могут привести к недоступности или потере данных, если не обрабатывать их корректно. Мониторинг работоспособности брокеров имеет первостепенное значение для отказоустойчивости.
• Сетевые проблемы: Сетевые разделы или высокая задержка между брокерами или между клиентами и брокерами могут серьезно повлиять на производительность и стабильность кластера.

Ключевые метрики Kafka для мониторинга

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

Метрики уровня брокера

Эти метрики дают представление о работоспособности и производительности отдельных брокеров Kafka.

• Метрики запросов:

  • kafka.network.RequestMetrics.RequestsPerSec (Скорость входящих запросов)
  • kafka.network.RequestMetrics.TotalTimeMs (Общее время обработки запросов)
  • kafka.network.RequestMetrics.ResponseQueueTimeMs (Время в очереди ответов)
  • kafka.network.RequestMetrics.LocalTimeMs (Время, затраченное на брокере)
  • kafka.network.RequestMetrics.RemoteTimeMs (Время, затраченное на связь с другими брокерами)
  • kafka.network.RequestMetrics.TotalBytesInPerSec и TotalBytesOutPerSec (Сетевой трафик)

• Метрики журналов:

  • kafka.log.Log.Size (Размер сегментов журнала на диске)
  • kafka.log.Log.N.MessagesPerSec (Скорость записи сообщений в сегмент журнала)
  • kafka.log.Log.N.BytesPerSec (Скорость записи байтов в сегмент журнала)
  • kafka.log.Log.N.LogFlushStats.LogFlushRateAndTimeMs (Скорость и время сброса сегментов журнала)

• Метрики контроллера: (Важны для выбора лидера и управления разделами)

  • kafka.controller.Controller.ControllerStateChangesPerSec
  • kafka.controller.Controller.LeaderChangesPerSec

• Метрики JVM: (Необходимы для понимания использования ресурсов брокера)

  • kafka.server:type=jvm,name=HeapMemoryUsage
  • kafka.server:type=jvm,name=NonHeapMemoryUsage
  • kafka.server:type=jvm,name=GarbageCollection
  • kafka.server:type=jvm,name=Threads

Метрики уровня темы

Эти метрики фокусируются на производительности и работоспособности конкретных тем Kafka.

• Недореплицированные разделы:

  • kafka.cluster.PartitionReplicaCount.UnderReplicatedPartitions (Количество разделов с меньшим количеством реплик, чем требуется)
  • Оповещение по этой метрике критически важно для долговечности и доступности данных.

• Офлайн-разделы:

  • kafka.cluster.PartitionState.OfflinePartitionsCount (Количество разделов, которые недоступны)
  • Высокое значение указывает на серьезную проблему с лидерством разделов или доступностью брокеров.

• Скорость выборов лидера:

  • kafka.controller.Controller.LeaderChangesPerSec (Скорость перевыборов лидера)
  • Всплеск может указывать на нестабильность или сбои брокеров.

Метрики группы потребителей

Эти метрики жизненно важны для понимания отставания потребителей и скорости обработки ваших приложений.

• Отставание потребителей: Часто это не прямая метрика Kafka, а вычисляемая путем сравнения последнего смещения, произведенного в тему, с последним смещением, потребленным группой. Инструменты мониторинга обычно предоставляют этот расчет.

  • Критическое оповещение: Высокое отставание потребителей (например, превышение определенного порога в течение длительного периода) указывает на то, что потребители отстают.

• Метрики запросов на выборку (с точки зрения потребителя):

  • kafka.consumer.Fetcher.MaxLag
  • kafka.consumer.Fetcher.MinFetchWaitMs
  • kafka.consumer.Fetcher.MaxFetchWaitMs

Внедрение решений для мониторинга

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

JMX и Prometheus

Брокеры Kafka предоставляют множество метрик через JMX (Java Management Extensions). Такие инструменты, как Prometheus, могут собирать эти JMX-метрики с помощью адаптера, например jmx_exporter.

1. Включите JMX: В Kafka JMX обычно включен по умолчанию. Убедитесь, что порт JMX доступен.
2. Настройте jmx_exporter: Загрузите и настройте jmx_exporter для предоставления JMX-метрик Kafka в формате, совместимом с Prometheus. Вам понадобится YAML-файл конфигурации, указывающий, какие MBeans собирать. Пример фрагмента конфигурации jmx_exporter для JMX Kafka: jmx_exporter/example_configs/kafka-2-0-0.yml (часто находится в репозитории jmx_exporter)
3. Настройте Prometheus: Добавьте цель в конфигурацию Prometheus для сбора данных с конечной точки, предоставляемой jmx_exporter, работающим вместе с вашими брокерами Kafka.

   scrape_configs:
     - job_name: 'kafka'
       static_configs:
         - targets: ['<kafka-broker-ip>:9404'] # Порт по умолчанию для jmx_exporter
   

4. Визуализируйте с помощью Grafana: Используйте Grafana для создания панелей мониторинга, отображающих эти метрики Prometheus. Готовые панели мониторинга Kafka доступны на Grafana Labs.

Специализированные инструменты мониторинга Kafka

• Kafka Manager (ранее Yahoo Kafka Manager): Популярный веб-инструмент для управления кластерами Kafka. Он предоставляет статус брокеров, проверку тем, мониторинг отставания потребителей и управление разделами.
• CMAK (Cluster Manager for Apache Kafka): Форк Kafka Manager, активно поддерживаемый и предлагающий аналогичные функции.
• Lenses.io / Confluent Control Center: Коммерческие предложения, предоставляющие расширенные возможности мониторинга, управления и визуализации данных Kafka.
• Стеки мониторинга Kafka с открытым исходным кодом: Комбинации, такие как стек ELK (Elasticsearch, Logstash, Kibana) с журналами Kafka или стек TICK (Telegraf, InfluxDB, Chronograf, Kapacitor) для данных временных рядов.

Настройка эффективного оповещения

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

Критические оповещения для настройки:

• Недореплицированные разделы > 0: Это оповещение высокого приоритета, указывающее на потенциальную потерю данных или недоступность. Требуется немедленное расследование.
• Количество офлайн-разделов > 0: Аналогично недореплицированным разделам, означает разделы, которые полностью недоступны.
• Высокое отставание потребителей: Определите порог на основе допустимости устаревших данных для вашего приложения. Оповещайте, когда отставание превышает этот порог в течение определенного времени (например, 5 минут). Пример PromQL (концептуально для Prometheus/Grafana):

  avg_over_time(kafka_consumergroup_lag_max{group="your-consumer-group"}[5m]) > 1000
  

  Примечание: Точное имя метрики и способ расчета отставания будут зависеть от вашей настройки мониторинга (например, использование собственных метрик Kafka, kafka-exporter или метрик на стороне клиента).
• Использование ЦП/памяти/диска брокера: Оповещайте, когда использование превышает заданные пороги (например, 80% для ЦП/памяти, 90% для диска). Дисковое пространство особенно критично для Kafka.
• Высокая задержка запросов: Оповещайте о длительном увеличении RequestMetrics.TotalTimeMs или определенных типов запросов (например, Produce, Fetch).
• Перезапуск/недоступность брокера: Настройте оповещения на случай, когда брокер Kafka становится недоступным или перестает сообщать метрики.
• Всплески скорости выборов лидера: Оповещайте о необычно высокой скорости выборов лидера, что может указывать на нестабильность.

Интеграция инструментов оповещения

Ваша настройка Prometheus может интегрироваться с менеджерами оповещений, такими как Alertmanager. Alertmanager обрабатывает дедупликацию, группировку и маршрутизацию оповещений в различные каналы уведомлений, такие как электронная почта, Slack, PagerDuty и т. д.

• Пример конфигурации Alertmanager (alertmanager.yml):

  route:
    group_by: ['alertname', 'cluster', 'service']
    receiver: 'default-receiver'
    routes:
      - receiver: 'critical-ops'
        match_re:
          severity: 'critical'
        continue: true
  
  receivers:
    - name: 'default-receiver'
      slack_configs:
        - channel: '#kafka-alerts'
  
    - name: 'critical-ops'
      slack_configs:
        - channel: '#kafka-critical'
      pagerduty_configs:
        - service_key: '<your-pagerduty-key>'
  

Лучшие практики мониторинга и оповещения Kafka

• Установите базовые показатели: Понимайте нормальное поведение вашего кластера Kafka. Это поможет установить значимые пороги оповещений и выявлять аномалии.
• Уровневая система оповещений: Различайте критические оповещения, требующие немедленных действий, и информационные оповещения, которые требуют проверки, но не обязательно требуют экстренного реагирования.
• Автоматизируйте действия: Для распространенных проблем (например, предупреждения о дисковом пространстве) рассмотрите возможность автоматизации действий по исправлению, где это безопасно.
• Мониторинг слоя метаданных: Старые кластеры Kafka обычно зависят от ZooKeeper, в то время как более новые развертывания могут использовать режим KRaft. Мониторируйте тот кворум метаданных, который фактически использует ваш кластер.
• Мониторинг сети: Убедитесь, что сетевое соединение и задержка между брокерами и клиентами находятся в допустимых пределах.
• Регулярно просматривайте панели мониторинга: Не полагайтесь только на оповещения. Регулярно просматривайте панели мониторинга, чтобы выявлять тенденции и потенциальные проблемы до того, как они вызовут оповещения.
• Тестируйте оповещения: Периодически тестируйте систему оповещения, чтобы убедиться, что уведомления отправляются правильно и доходят до нужных людей.

Оповещайте о симптомах, на которые читатели могут реагировать

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

UnderReplicatedPartitions > 0 требует действий, потому что это означает, что по крайней мере один раздел имеет меньше синхронизированных реплик, чем ожидалось. Первая проверка — работоспособность брокера, затем диск, сеть и отставание fetcher реплик. Если это быстро проходит во время перезапуска по очереди, это может быть ожидаемо. Если значение остается ненулевым, рассматривайте это как риск для долговечности и доступности.

OfflinePartitionsCount > 0 более срочно. Раздел без активного лидера не может обслуживать обычный трафик Produce или Fetch. Это оповещение должно включать контекст кластера и брокера и должно вызывать оповещение для производственных кластеров.

Отставание потребителей важно, но требует нюансов. Отставание в 10 000 записей может быть безвредным для низкоприоритетной пакетной темы, работающей ночью, и серьезным для конвейера обнаружения мошенничества. Оповещайте об отставании относительно цели группы потребителей: устойчивое отставание, отставание, увеличивающееся быстрее, чем потребители могут восстановиться, или расчетное время отставания, если ваши инструменты могут его вычислить.

Оповещения о диске должны срабатывать до того, как у Kafka не останется места для записи. Брокеры Kafka по своей конструкции являются системами с интенсивным использованием диска, и полные диски могут вызвать каскадные проблемы. Связывайте оповещения об использовании диска с контекстом каталога журналов, чтобы дежурный мог видеть, является ли проблема одним брокером, одной точкой монтирования или проблемой политики хранения во всем кластере.

Практичная компоновка панели мониторинга

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

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

Третий ряд должен быть сосредоточен на репликации: отставание fetcher реплик, события уменьшения/увеличения синхронизированных реплик, скорость выборов лидера и распределение разделов по брокерам. Если один брокер имеет гораздо больше лидеров или горячих разделов, чем остальные, кластер может выглядеть здоровым в целом, в то время как один узел перегружен.

Четвертый ряд должен быть сосредоточен на потребителях: отставание по группам и темам, записей, потребленных в секунду, скорость ребалансировки, где это доступно, и метрики ошибок потребителей от инструментирования приложений. Метрики брокера не могут сказать вам, застрял ли потребитель внутри медленной записи в базу данных после выборки сообщений.

Где все еще помогают проверки командной строки

Даже с панелями мониторинга инструменты командной строки Kafka полезны для подтверждения того, что кластер "думает".

Проверьте состояние разделов темы:

kafka-topics.sh --bootstrap-server broker1:9092 --describe --topic orders

Ищите разделы с отсутствующими лидерами, реплики, которые не находятся в ISR, или неравномерное размещение лидеров.

Проверьте отставание потребителей:

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --describe \
  --group billing-worker

Вывод помогает отделить "вся группа отстает" от "один раздел застрял". Один застрявший раздел часто указывает на сообщение-отравитель, горячий ключ или один экземпляр потребителя, который нездоров.

Проверьте версии API брокера, когда клиенты ведут себя странно:

kafka-broker-api-versions.sh --bootstrap-server broker1:9092

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

Как избежать шумных оповещений Kafka

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

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

Каждое оповещение должно иметь вероятного владельца. Полный диск брокера принадлежит платформенной или операционной команде. Отставание потребителей для billing-worker может принадлежать команде приложения. Если все оповещения Kafka направляются в один канал без указания владельца, люди научатся их игнорировать.

Нюансы слоя метаданных и версий

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

Будьте осторожны со старыми руководствами, которые утверждают, что каждый кластер Kafka полагается на ZooKeeper. Это было правдой в течение многих лет, но более новые развертывания Kafka могут его не использовать. Ваш runbook должен соответствовать кластеру, который вы фактически запускаете.

Runbook'и важнее идеальных панелей мониторинга

Оповещение без runbook'а оставляет дежурного гадать. Для каждого критического оповещения напишите первые проверки, распространенные причины и путь эскалации. Для недореплицированных разделов runbook может сказать: проверьте доступность брокера, проверьте использование диска, проверьте сетевые ошибки, проверьте недавние развертывания или перезапуски, определите затронутые темы и решите, приостанавливать ли обслуживание.

Для отставания потребителей runbook может сказать: определите, отстают ли все разделы или один раздел, проверьте работоспособность развертывания потребителя, проверьте недавние ошибки приложения, проверьте downstream-зависимости и поищите ребалансировки. Если один раздел застрял, найдите текущее смещение и безопасно проверьте сообщение с помощью внутренних инструментов, а не пропускайте смещения вслепую.

Хороший мониторинг не устраняет инциденты. Он делает первые несколько решений быстрее и менее эмоциональными.

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