问题发现
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”，可以同时支持日志删除和日志压缩两种清除策略。
# 设置保留时间为 7 天（默认 168小时）
log.retention.hours=168
# 每个日志分区的最大大小，超过后 Kafka 会删除最早的日志。
log.retention.bytes=1073741824 # 日志删除的清除策略
log.cleanup.policy=delete
Broke端查看目前没有问题，会不会是Topic对应设置了参数，覆盖了Broke的参数。查看Topic端的对应参数设置
kafka-topics.sh --bootstrap-server <broker-list> --describe --topic <your-topic-name>发现topic的config中有：
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 配置：
# 将保留时间设置为 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或者删除该属性
kafka-configs.sh --bootstrap-server <broker> --entity-type topics --entity-name ASS_DEFAULT_DEV --alter --delete-config cleanup.policy --delete-config retention.ms再次查看topic，属性已经没了，消息保留时间也正常了
