Observability Kafka — consumer lag alerts, traceparent и DLQ-size

Опирается на правила: R-KFK-OBS-1 … R-KFK-OBS-4 и R-KFK-OBS-X1 из Kafka Style Guide → раздел 8. Observability.

Важно знать

• Spring Kafka автоматически экспортирует через Micrometer: kafka_consumer_lag, kafka_producer_record_error_total, kafka_consumer_records_consumed_total.
• kafka_consumer_lag — главный health-сигнал. Растущий lag = consumer не справляется или лежит.
• Alert на lag > N для критичных topic'ов в течение 5 минут — инцидент.
• traceparent в Kafka headers — distributed trace продолжается через producer/consumer.
• DLQ-size alert обязательный — каждое сообщение в DLQ требует разбора.
• Без consumer-lag alerts пропадание сообщений замечается через жалобы пользователей.

Kafka pipeline без observability — это чёрный ящик: producer публикует, consumer обрабатывает, но что между ними и как быстро — никто не видит. Consumer lag и DLQ-size — два маркера, по которым ops понимает «жив ли pipeline».

Автоматические метрики

R-KFK-OBS-1: Spring Kafka подключён к Micrometer.

Включается через actuator + observation-enabled в listener-config:

spring:
  kafka:
    listener:
      observation-enabled: true

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

Consumer lag — главный сигнал

R-KFK-OBS-2: alert на lag.

- alert: KafkaConsumerLagHigh
  expr: |
    max by (topic, consumer_group) (kafka_consumer_lag) > 1000
  for: 5m
  annotations:
    summary: "Consumer {{ $labels.consumer_group }} лагает на topic {{ $labels.topic }}"
    runbook: https://runbooks.internal/kafka-consumer-lag

Что значит растущий lag:

• Consumer лежит (CrashLoop, OOM). Срочно посмотреть pod logs.
• Consumer не справляется. Concurrency недостаточен; обработка одного сообщения слишком долгая; внешняя система отдаёт slow response.
• Rebalance в петле. max.poll.interval.ms превышается, постоянные rebalances.

Threshold зависит от критичности:

• Money events — > 100 (за минуту накапливается серьёзно): SMS / Telegram алерт.
• Order events — > 1000: ticket, разбираемся.
• Analytics — > 100000: low-priority, ok терпеть час.

Lag измеряется per (consumer_group, topic, partition). Высокий lag только на одной partition часто означает hot key (все события одного aggregate туда летят).

Traceparent в Kafka headers

R-KFK-OBS-3: distributed trace продолжается через Kafka.

Producer side (auto через OTel + Spring Kafka):

HTTP request → handler @Transactional
              → outbox INSERT
              → outbox-relay → KafkaTemplate.send → headers["traceparent"] = current trace

Consumer side:

@KafkaListener → headers["traceparent"] → continue span
              → @Transactional
              → handler → DB UPDATE

В Tempo/Jaeger видно полный trace от HTTP request → DB write → Kafka publish → another service consume → its DB write. Это даёт debugging для distributed flow.

Требует:

• opentelemetry-spring-boot-starter подключён (см. Tracing).
• spring.kafka.listener.observation-enabled: true.

После этого ничего custom-кода не нужно. Любой @KafkaListener автоматически становится частью distributed trace.

DLQ size alert

R-KFK-OBS-4: см. Retry topic + DLQ → DLQ monitoring.

Каждый DLQ topic нуждается в alert. Threshold per business-criticality.

Что запрещено

Отсутствие consumer-lag alerts

R-KFK-OBS-X1: без алертов — невидимая проблема.

Сценарий: deploy v1.5, новый bug в listener — обрабатывает 100 events/s вместо 1000. Lag растёт линейно. Через 6 часов — миллион messages в backlog. Заказы клиентов «не подтверждаются» — clients пишут в support.

С alert на lag > 1000 за 5 минут — операторы знают через 5 минут после деплоя, успевают rollback.

Что запрещено — таблица

Куда дальше

• Kafka → раздел 8. Observability — нормативные формулировки.
• Observability → Tracing — OpenTelemetry, traceparent.
• Observability → SLO и алерты — multi-window burn rate.
• Observability → Metrics — стандартные tags.
• Consumer — max.poll.interval.ms, rebalance.
• Retry topic + DLQ — DLQ alert detail.
• Configuration — observation-enabled.