特定Kafka Topic的retention.ms配置未生效问题排查求助

针对你遇到的mytopic1日志超期未清理、其他同配置topic正常的问题，可按以下方向逐一排查：

1. 验证Topic实际生效的配置 #

不要仅依赖Strimzi的KafkaTopic CR配置，直接通过Kafka命令行查看topic的实际生效参数，确认retention.ms是否正确应用：

kafka-configs.sh --describe --topic mytopic1 --bootstrap-server <kafka-bootstrap-service-name>:9092

重点检查输出中是否存在retention.ms=259200000，同时确认没有其他覆盖性配置（如retention.bytes被设置为极大值，导致优先按空间保留而非时间）。

2. 检查消费者组偏移量状态 #

Kafka不会删除被活跃消费者组未消费的日志段，如果有消费者组订阅mytopic1但长期未提交偏移或停滞，会阻止日志清理。执行以下命令查看相关消费者组的偏移情况：

kafka-consumer-groups.sh --describe --group <目标消费者组名称> --bootstrap-server <kafka-bootstrap-service-name>:9092

关注CURRENT-OFFSET与LOG-END-OFFSET的差值，若CURRENT-OFFSET远滞后于LOG-END-OFFSET且长时间无更新，说明该消费者组未正常消费，导致旧日志无法被清理。

3. 分析日志段文件的属性与状态 #

进入mytopic1-0的日志目录，检查日志段的细节：

• 查看日志段的修改时间：

  ls -lrt /var/lib/kafka/data/kafka-log0/mytopic1-0/*.log
  

  Kafka的日志清理基于日志段的最后修改时间，而非消息的时间戳。如果某段日志仍被持续写入（如延迟消息），其修改时间会更新，不会触发清理。
• 查看日志段的偏移范围：

  kafka-dump-log.sh --files /var/lib/kafka/data/kafka-log0/mytopic1-0/00000000000000000000.log
  

  确认该段的起始/结束偏移，结合消费者偏移判断是否属于应被清理的范围。

4. 排查日志清理线程的运行状态 #

查看Kafka Broker的日志，搜索日志清理相关的记录，确认是否有针对mytopic1的清理异常：

grep -i "cleaner\|delete" /var/log/kafka/kafka.log

重点关注是否存在清理线程报错、资源不足（如内存不足导致清理无法执行）或清理任务被阻塞的信息。

5. 检查未完成事务的影响 #

如果mytopic1使用了事务性生产者，未提交/未终止的事务会锁定对应的日志段，阻止清理。可通过以下命令查看分区的事务状态：

kafka-log-dirs.sh --describe --topic-list mytopic1 --bootstrap-server <kafka-bootstrap-service-name>:9092

同时在Broker日志中搜索transaction关键词，排查是否有事务超时、异常未处理的情况。

6. 验证磁盘权限与inode状态 #

确认Kafka进程对mytopic1-0目录有完整的读写权限：

ls -ld /var/lib/kafka/data/kafka-log0/mytopic1-0

另外检查磁盘inode是否耗尽（inode耗尽会导致文件无法删除/创建，间接影响日志清理）：

df -i

7. 确认Strimzi Operator的配置同步状态 #

查看Strimzi Cluster Operator的日志，确认mytopic1的配置是否同步成功：

# 在Operator Pod中执行
grep "mytopic1" /var/log/strimzi/cluster-operator.log

检查是否存在配置同步失败的报错，同时验证KafkaTopic CR的status.observedGeneration是否与spec.generation一致（若不一致说明配置未同步生效）。

内容的提问来源于stack exchange，提问作者Johnathan