问题发现
kafka下游消费的开发说没有消息,刚触发消息,按理说应该不会消失才对。
通过Eagle监控发现消息的offset没了
然后到kafka log目录,查看log发现有删除日志
查看了消费者组,只有一个消费者组消费,咨询了开发,确认没有进行消息删除操作
问题排查
查看kafka关于日志保留策略 、消息清理的机制
Kafka的日志清除策略
Kafka中每一个分区partition都对应一个日志文件,而日志文件又可以分为多个日志分段文件,这样也便于日志的清理操作。
Kafka提供了两种日志清除策略:
(1)日志删除(Log Deletion) 按照一定的保留策略来直接删除不符合条件的日志分段。
(2)日志压缩(Log Compaction) 针对每个消息的key进行整合,对于有相同key的不同value值,只保留最后一个版本。
在kafka server.propertie 中通过broker端 的参数log.cleanup.policy 来设置日志的清除策略,此参数的默认值是"delete" ,即采用日志删除的清除的策略。如果要采用日志压缩的清除策略,则需要将log.cleanup.policy设置为"compact",并且还需要将log.cleaner.enable(默认值为true)设定为true。
通过将log.cleanup.policy设置为"delete,compact",可以同时支持日志删除和日志压缩两种清除策略。
bash
# 设置保留时间为 7 天(默认 168小时)
log.retention.hours=168
# 每个日志分区的最大大小,超过后 Kafka 会删除最早的日志。
log.retention.bytes=1073741824
# 日志删除的清除策略
log.cleanup.policy=delete
Broke端查看目前没有问题,会不会是Topic对应设置了参数,覆盖了Broke的参数。查看Topic端的对应参数设置
bash
kafka-topics.sh --bootstrap-server <broker-list> --describe --topic <your-topic-name>
发现topic的config中有:
bash
Topic: ASS_DEFAULT_DEV TopicId: ZtQctrQrRc6YQHk3PsXWTQ PartitionCount: 8 ReplicationFactor: 2
Configs: cleanup.policy=delete,retention.ms=1000
配置解释:
cleanup.policy=delete
这意味着 Kafka 会根据 retention.ms 或 retention.bytes 配置来删除过期的消息。默认情况下,cleanup.policy 设置为 delete,这表示 Kafka 会定期删除日志文件中的过期数据。
retention.ms=1000
这表示 Kafka 中该 Topic 的消息会在 1000 毫秒(即 1 秒)后过期,超时的消息会被删除。这是一个非常短的保留时间,意味着数据几乎立刻就会被删除。因此,Topic 中的消息可能在非常短的时间内就会被清理掉。
解决方案
更正 retention.ms 配置:
bash
# 将保留时间设置为 7 天
kafka-configs.sh --bootstrap-server 10.20.243.19:9092 --entity-type topics --entity-name ASS_DEFAULT_DEV --alter --add-config retention.ms=604800000
或者删除该属性
bash
kafka-configs.sh --bootstrap-server <broker> --entity-type topics --entity-name ASS_DEFAULT_DEV --alter --delete-config cleanup.policy --delete-config retention.ms
再次查看topic,属性已经没了,消息保留时间也正常了