AWS MSK集群中Kafka Log Cleaner运行状态及日志缺失问题问询

针对你遇到的AWS MSK 2.8.1集群中Log Cleaner似乎未运行的问题，我结合Kafka和MSK的特性整理了以下分析和验证步骤：

AWS MSK默认是开启Log Cleaner的，但首先得排除配置被修改的可能：

• 通过AWS CLI或控制台检查核心配置：
  执行这条CLI命令查看集群的配置详情：

  aws kafka describe-cluster-configuration --cluster-arn <你的集群ARN>
  

  或者直接登录MSK控制台，进入集群的「Configuration」页面，找到log.cleaner.enable参数。如果它被设为false，那Log Cleaner确实没在运行，需要修改配置并重启集群生效。

看不到"cleaner"或"cleaned"日志，很可能是日志级别被过滤了：

• 检查Broker的日志级别配置：
  Kafka的Log Cleaner日志默认是INFO级别，但MSK的默认日志配置可能把这类日志过滤掉了。你需要确认集群配置中的log4j.logger.kafka.log.LogCleaner是否设置为INFO或DEBUG——如果是WARN或ERROR，只有出现错误时才会输出日志，常规的清理操作日志就看不到了。
• 确认CloudWatch日志流的订阅范围：
  登录CloudWatch控制台，找到你的MSK Broker日志组，检查日志流是否包含kafka.log.LogCleaner相关的日志类别。有时候日志组可能只订阅了核心Broker日志，没包含Cleaner的日志条目。

即使Log Cleaner在运行，也得满足特定条件才会执行清理，你的消息存了2周没被清理，可能是这些条件没达标：

• 可清理消息占比阈值：
  默认的log.cleaner.min.cleanable.ratio是0.5，意思是只有当topic日志中可被清理的旧消息（相同key的历史消息）占比超过50%时，才会触发清理。如果你的topic一直在写入新消息，但旧消息占比还没到阈值，Cleaner就不会启动。
• Segment文件的滚动条件：
  Log Cleaner只会处理已经被滚动（roll）的segment文件，不会碰当前活跃的segment。默认log.segment.bytes是1GB，如果你的topic消息量很小，segment还没写满，或者长时间没有新消息写入导致segment没被滚动，旧的可清理消息就会一直留在活跃segment里。
• 辅助保留时间的限制：
  对于compact类型的topic，log.retention.ms（默认7天）是辅助清理条件——只有超过这个时间的segment才会被考虑清理。不过你说消息已经存了2周，这个条件应该满足，但还是建议确认下该topic的这个参数配置。

如果日志查不到，可以用这些更直接的方式验证：

• 查看JMX指标：
  通过JMX工具（比如JConsole、Prometheus+Grafana）连接到MSK Broker，查看这些关键指标：
  • kafka.log:type=LogCleaner,name=CleanedSegmentsPerSec：每秒清理的segment数量，非零则说明Cleaner在运行
  • kafka.log:type=LogCleaner,name=MaxCleanTimeMs：单次清理的最大耗时，有数值则代表有清理操作
    注意：MSK需要开启JMX访问权限，你可能需要通过VPC内的EC2实例来连接。
• 手动触发清理测试：
  在能访问Broker的机器上，执行这条命令手动触发指定compact topic的清理：

  kafka-run-class.sh kafka.log.LogCleaner --topic <你的compact topic名称> --bootstrap-server <你的Broker地址>
  

  执行后再去CloudWatch日志里搜索相关关键词，或者查看topic的消息是否有被清理，就能判断Cleaner是否正常工作。
• 检查segment文件（需权限）：
  如果能访问MSK Broker的EBS日志卷，找到对应compact topic的日志目录，查看是否有.cleaned后缀的文件，或者旧的segment文件是否被合并/删除——这也是Cleaner运行过的痕迹。

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