Что делать если в Kafka мало места при большом объеме сообщений

Что проверяют

Знаете ли вы, чем управляется хранение в Kafka, и понимаете ли разницу между настройками брокера и настройками топика. В JVM-командах дополнительно смотрят, помните ли вы про служебные топики, которые создаёт само приложение: именно они часто и съедают диск незаметно.

Как отвечать

Начните с измерения, потом переходите к настройкам:

• найти виновников: kafka-log-dirs.sh --describe, метрики размера логов через JMX, распределение по партициям;
• быстро освободить место: снизить retention.ms или retention.bytes у самых крупных топиков через kafka-configs.sh либо программно через AdminClient. Важно: брокерские log.retention.* это значения по умолчанию, топик со своей настройкой их не подхватит;
• учитывать, что retention.bytes считается на партицию, а не на топик;
• ускорить освобождение: удаляются только закрытые сегменты, поэтому при редких сообщениях уменьшают размер сегмента и время его закрытия;
• включить сжатие на продюсере: в Spring Boot это свойство продюсера, в чистом клиенте compression.type в конфигурации ProducerConfig. Алгоритмы zstd и lz4 дают лучшее соотношение, а поскольку сжимается батч целиком, вместе с этим увеличивают задержку накопления и размер батча;
• сократить сам объём: перейти с объёмного JSON на схемный бинарный формат, укоротить ключи;
• если приложение на Kafka Streams, проверить служебные топики: changelog и топики перераспределения живут по своим настройкам хранения.

Где спотыкаются

Меняют log.retention.hours на брокере и ждут, что освободятся существующие топики. Топик с собственным retention.ms продолжит жить по своей настройке, и это самая частая причина жалобы «уменьшил хранение, а место не вернулось».

Ставят политику очистки compact вместо delete, считая её сжатием. Компактизация оставляет последнее значение по ключу: для журнала событий это потеря данных, а для топика без ключей она не даёт вообще ничего.

Считают потребность в месте по среднему трафику и без репликации. Фактор репликации умножает объём, а во время переназначения партиций копии какое-то время лежат и на старом, и на новом брокере, поэтому запас планируют от пикового потока.