Мониторинг Kafka с помощью Proto Observability

Сбор метрик Kafka

Интеграция kafka собирает метрики Apache Kafka двумя путями:

• JMX — метрики брокера, топиков, репликации, обработки запросов и сессий ZooKeeper.
• Kafka Admin API — offset партиций (kafka_broker_offset) и лаг групп консьюмеров (kafka_consumer_offset, kafka_consumer_lag).

Конфигурация Kafka

JMX Remote должен быть включён и доступен с хоста, на котором работает агент. Конкретные флаги зависят от способа запуска брокера.

• Способ запуска Kafka:
• Хост / systemd
• Kubernetes

export KAFKA_JMX_PORT=9101
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote=true \
  -Dcom.sun.management.jmxremote.port=9101 \
  -Dcom.sun.management.jmxremote.rmi.port=9101 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Djava.rmi.server.hostname=<FQDN_или_IP_хоста>"

env:
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP
  - name: KAFKA_JMX_PORT
    value: "9101"
  - name: KAFKA_JMX_HOSTNAME
    value: "$(POD_IP)"
  - name: KAFKA_JMX_OPTS
    value: >-
      -Dcom.sun.management.jmxremote=true
      -Dcom.sun.management.jmxremote.port=9101
      -Dcom.sun.management.jmxremote.rmi.port=9101
      -Dcom.sun.management.jmxremote.authenticate=false
      -Dcom.sun.management.jmxremote.ssl=false
      -Djava.rmi.server.hostname=$(POD_IP)      
ports:
  - name: jmx
    containerPort: 9101

Конфигурация ProtoOBP агента

Если агент запускается в виде службы на хосте

1. Создайте файл /etc/protoobp-agent/conf.d/kafka.d/conf.yaml:

   init_config:
     is_jmx: true
     collect_default_metrics: true
     new_gc_metrics: true
   
   instances:
     - host: localhost
       port: 9101
       # user: username       # если на JMX включена аутентификация
       # password: password
       monitor_unlisted_consumer_groups: true
       monitor_all_broker_highwatermarks: true
   

2. Перезапустите агента: systemctl restart protoobp-agent.

Если агент запускается в виде Docker контейнера

Добавьте autodiscovery-лейблы к контейнеру брокера. В docker-compose.yaml:

labels:
  com.protoobp.ad.check_names: '["kafka"]'
  com.protoobp.ad.init_configs: '[{"is_jmx": true, "collect_default_metrics": true, "new_gc_metrics": true}]'
  com.protoobp.ad.instances: '[{"host": "%%host%%", "port": "9101", "monitor_unlisted_consumer_groups": true, "monitor_all_broker_highwatermarks": true}]'

Если агент запускается в Kubernetes

Используйте annotation-based autodiscovery на Pod’е Kafka. Полностью рабочий пример развёртывания:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafka
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kafka
  template:
    metadata:
      labels:
        app: kafka
        tags.proto.group/service: "my-kafka"   # тег service для метрик
        tags.proto.group/env: "dev"            # тег env
        tags.proto.group/version: "3.0"        # тег version
      annotations:
        ad.proto.group/kafka.checks: |-
          {
            "kafka": {
              "init_config": {
                "is_jmx": true,
                "collect_default_metrics": true,
                "new_gc_metrics": true
              },
              "instances": [
                {
                  "host": "%%host%%",
                  "port": "9101",
                  "monitor_unlisted_consumer_groups": true,
                  "monitor_all_broker_highwatermarks": true
                }
              ]
            }
          }          
    spec:
      containers:
        - name: kafka
          image: confluentinc/cp-kafka:7.7.0
          ports:
            - name: broker
              containerPort: 9092
            - name: jmx
              containerPort: 9101
          env:
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: KAFKA_JMX_PORT
              value: "9101"
            - name: KAFKA_JMX_HOSTNAME
              value: "$(POD_IP)"
            - name: KAFKA_JMX_OPTS
              value: >-
                -Dcom.sun.management.jmxremote=true
                -Dcom.sun.management.jmxremote.port=9101
                -Dcom.sun.management.jmxremote.rmi.port=9101
                -Dcom.sun.management.jmxremote.authenticate=false
                -Dcom.sun.management.jmxremote.ssl=false
                -Djava.rmi.server.hostname=$(POD_IP)                
            # ... остальные переменные Kafka (KAFKA_PROCESS_ROLES, KAFKA_LISTENERS и т.д.)

Проверка

Убедитесь, что чек запустился и собирает метрики:

docker exec protoobp-agent agent status | grep -A 8 "^    kafka$"

Ожидаемый вывод — status : OK и metric_count > 0 для каждого instance:

kafka
  instance_name : kafka-localhost-9101
  message       : <no value>
  metric_count  : 60
  status        : OK

Полный список найденных JMX-атрибутов:

docker exec protoobp-agent agent jmx list collected

Собираемые метрики

Все метрики Kafka имеют тип gauge — содержат мгновенное значение на момент сбора. Метрики, в имени которых уже стоит суффикс _rate, — это скорость в секунду, рассчитанная самой Kafka и пересланная агентом без дополнительной обработки.

Лейблы

Общие (на JMX-метриках)

Добавляются агентом и ProtoOBP backend’ом:

JMX-атрибуты MBean

На всех JMX-метриках, кроме kafka_can_connect (см. ниже):

kafka_can_connect относится к самому JMX-подключению, MBean у неё нет — вместо jmx_domain/type/name она несёт env и jmx_server.

Специфичные для Kafka

Метрики Admin API

kafka_broker_offset, kafka_consumer_offset и kafka_consumer_lag собираются через Kafka Admin API в обход JMX и несут только узкий набор: host, topic, partition и consumer_group (последний — у *_offset и *_lag). Базовых JMX-меток и enrichment-а контейнера у них нет — учитывайте это при джоинах с другими сериями в PromQL.

Здоровье JMX-подключения

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

Несут базовый набор JMX-меток (host, instance, jmx_domain, type, name).

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

Несут лейбл topic дополнительно к базовому JMX-набору.

Offset и consumer lag (Kafka Admin API)

Несут лейблы host, topic, partition (плюс consumer_group для двух последних) — JMX-атрибуты не применяются.

Метрики репликации

Несут базовый набор JMX-меток.

Обработка запросов

Доп. метка request (Produce / FetchConsumer / FetchFollower / Metadata / UpdateMetadata) — на метриках времени; delayedOperation — на purgatory-метриках.

Сессии и ZooKeeper

Несут базовый набор JMX-меток.

Ключевые метрики для дашбордов и алертов

Доступность брокера

• kafka_can_connect == 0 — алерт: JMX недоступен (агент не получает метрики).
• kafka_replication_active_controller_count — sum() != 1 по кластеру = split brain или нет контроллера.
• kafka_replication_offline_partitions_count > 0 — алерт: разделы без лидера.
• kafka_replication_unclean_leader_elections_rate > 0 — алерт: была потеря данных.

Целостность реплик

• kafka_replication_under_replicated_partitions > 0 — деградация репликации, дашборд per-broker.
• kafka_replication_under_min_isr_partition_count > 0 — продюсеры с acks=all начинают получать ошибки записи.
• kafka_replication_max_lag — растёт = follower не успевает за лидером.

Производительность брокера

• kafka_messages_in_rate, kafka_net_bytes_in_rate, kafka_net_bytes_out_rate — основные графики throughput.
• kafka_request_produce_time_99percentile, kafka_request_fetch_consumer_time_99percentile — латентность запросов.
• kafka_net_processor_avg_idle_pct_rate < 0.3 или kafka_request_handler_avg_idle_pct_rate < 0.3 — алерт: насыщение сетевых/обработчиков.
• kafka_request_channel_queue_size — растёт = бэклог запросов.

Consumer lag

• kafka_consumer_lag — основной SLI для консьюмеров: разбивка по consumer_group и topic, алерт по абсолютному порогу или росту через окно.
• kafka_consumer_offset без движения при ненулевом kafka_topic_messages_in_rate = группа замерла.

Топики

• kafka_topic_messages_in_rate, kafka_topic_net_bytes_in_rate — топ топиков по нагрузке, обнаружение всплесков.