Kafka 4.4.0 ввел DLQ и метрики ввода-вывода

Apache Kafka 4.4.0 вышла с 25 KIP и почти тысячей коммитов. Релиз добавляет поддержку dead-letter очередей для share-групп, новые метрики Linux I/O через JMX и механизм отложенной загрузки в tiered storage. Эти изменения влияют на мониторинг, обработку ошибок и затраты на хранение, поэтому командам стоит оценить их под свои нагрузки перед миграцией.

Новые возможности для продюсеров и брокеров

Share-группы получили dead-letter queues. Записи, которые превысили лимит доставок или были отклонены консьюмером, теперь можно перенаправлять в отдельный топик после поднятия share.version до 2. Настройка выполняется через пять динамических параметров, включая errors.deadletterqueue.topic.name и auto.create.topics.enable. Это снижает потерю данных при сбоях обработки, но требует отдельного мониторинга DLQ-топиков и планирования их очистки.

Dead-letter queue представляет собой отдельный топик, куда попадают сообщения, которые не удалось успешно обработать после нескольких попыток. В обычных consumer groups такие сообщения часто просто теряются или требуют ручного вмешательства. Появление DLQ в share-группах позволяет автоматизировать обработку ошибок и сохранять проблемные записи для последующего анализа. Однако это означает появление дополнительных топиков, которые тоже нужно мониторить, задавать для них политики retention и следить за тем, чтобы они не разрастались неконтролируемо.

Отложенная загрузка в tiered storage управляется параметрами remote.copy.lag.bytes и remote.copy.lag.ms. Брокер может держать больше данных локально перед копированием в удаленное хранилище, уменьшая избыточность. В нагруженных кластерах это сокращает сетевой трафик и стоимость S3-подобных хранилищ, однако увеличивает время восстановления при потере локальных дисков. Перед включением нужно пересчитать RPO и протестировать поведение при отказе узла.

Tiered storage разделяет данные на «горячие», которые хранятся на быстрых локальных дисках, и «холодные», перемещаемые в более дешевое объектное хранилище. Механизм отложенной загрузки дает возможность дольше держать данные локально, снижая частоту обращений к удаленному хранилищу. Это полезно для кластеров с высокой пропускной способностью, где копирование каждого байта сразу в S3 создает лишнюю нагрузку на сеть и увеличивает счета. С другой стороны, более длительное хранение данных только локально повышает риск их потери при отказе диска или узла, поэтому важно заранее оценить, насколько критична для бизнеса скорость восстановления и какой RPO приемлем.

Метрики и инструменты диагностики

Linux I/O метрики теперь передают все семь полей из /proc/self/io. Появились linux-disk-rchar, linux-disk-syscr и linux-disk-cancelled-write-bytes. С их помощью можно считать hit ratio page cache, выявлять write amplification и отслеживать нагрузку от log compaction. Метрики доступны через JMX, поэтому существующие дашборды в Grafana или Prometheus требуют обновления запросов.

Метрики из /proc/self/io показывают реальное количество байт, прочитанных и записанных процессом, включая операции через page cache и прямые системные вызовы. Раньше администраторы часто опирались только на метрики самого Kafka, которые не всегда отражали поведение операционной системы. Новые счетчики позволяют точнее понимать, насколько эффективно используется кеш страниц, не происходит ли избыточная запись одних и тех же данных и насколько сильно log compaction нагружает диск. Это особенно важно при выборе между увеличением памяти под page cache и покупкой более быстрых дисков.

Добавлена команда kafka-cluster.sh api-versions. Она показывает поддерживаемые версии API для брокеров и контроллеров и заменяет устаревший kafka-broker-api-versions.sh. Новый инструмент принимает как —bootstrap-server, так и —bootstrap-controller, что удобно при работе с кластерами в разных режимах.

Совместимость и подготовка к обновлению

Формат storage-директорий, созданных kafka-storage, больше не совместим вперед: версия брокера должна быть не ниже версии инструмента форматирования. При обновлении с 4.3 нужно перепроверить скрипты инициализации и при необходимости переформатировать директории. Кроме того, deprecated broker.id и Yammer-метрики GroupCoordinatorMetrics, их замена на Kafka Metrics произойдет в 5.0, поэтому уже сейчас стоит мигрировать конфиги и алерты.

В российских контурах чаще всего используют on-premise развертывания с самописными скриптами развертывания. Изменения в bootstrap-разрешении и unregister-контроллерах требуют обновления плейбуков Ansible или Kubernetes-манифестов. Метрики I/O и DLQ полезны для уже существующих мониторинговых систем, но их активация не критична, если текущие дашборды закрывают потребности.

Стоит ли обновляться сейчас

Релиз не ломает существующие продюсеры и консьюмеры, однако меняет поведение storage и добавляет новые конфиги. Если кластер использует share-группы или tiered storage, обновление дает ощутимые преимущества. В остальных случаях можно подождать 4.4.1, чтобы проверить исправления багов. Перед rollout обязательно протестировать на staging-кластере с реальной нагрузкой и обновить все скрипты, которые опираются на deprecated параметры.

Источник

Это краткий разбор материала Apache Kafka. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Kafka 4.4.0 ввел DLQ и метрики ввода-вывода.

Курс по теме — Каталог курсов Школы Больших Данных