不生效的设置

#设置日志只保留一个小时的
  "log.retention.hours": 1
#设置大于500M就自动删除
  "log.retention.bytes": "536870912"
#设置日志被标记删除后，保留多久彻底删除，1分钟
  "log.segment.delete.delay.ms": 60000
#设置多久扫描一次要清理的日志
  "log.cleanup.interval.mins": 3
kafka回收原理
 
kafka只会回收上个分片的数据
 
配置没有生效的原因就是，数据并没有分片，所以没有回收 
kafka什么时候分片？有个参数log.roll.hours
 
log.roll.hours 设置多久滚动一次，滚动也就是之前的数据就会分片分出去
 segment.bytes 设置日志文件到了多大就会自动分片 
  "log.retention.hours": 1
  "log.cleanup.policy": "delete"
  "log.retention.bytes": "536870912"
  "log.segment.delete.delay.ms": 60000
  "log.cleanup.interval.mins": 3
  "log.roll.hours": 1
  "segment.bytes": "536870913"
  "log.retention.check.interval.ms": 120000
  "retention.ms": "3600000"
  "retention.bytes": "536870912"
建议
 log.roll.hours
 retention.ms
 log.retention.hours
 设置的时间相同 
https://www.cnblogs.com/skycandy/p/11402214.html
 https://kafka.apache.org/documentation/#brokerconfigs
                    背景看了网上很多文档，说是要设置log.retention.hour等等参数。默认是保留7天，但我实测下来发现日志根本没有任何变化。目前我们的kafka，一天就有400多个G，保留七天大大增加了我们的服务器成本。不生效的设置#设置日志只保留一个小时的  "log.retention.hours": 1#设置大于500M就自动删除  "log.retention.bytes": "5...
				数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据
log.retention.bytes和log.retention.hours任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖。
在server.properties里设置log.retention.hours=1
启动Kafka后，新建一个终
				使用环境:Jdk 1.8
使用场景：生产环境海量数据，用kafka-console-consumer
消费kafka某时间段消息用于分析问题，生产环境海量数据，用kafka-console-consumer.sh只能消费全量，文件巨大，无法grep。
代码来源于博主：BillowX_ ，感谢分享
原贴地址：https://blog.csdn.net/weixin_35852328/article/details/105511784
使用方法见压缩包内；或者直接执行，参数不全时会打印使用方法。
由于logstash内存占用较大,灵活性相对没那么好,ELK正在被EFK逐步替代.其中本文所讲的EFK是Elasticsearch+Fluentd+Kfka,实际上K应该是Kibana用于日志的展示,这一块不做演示,本文只讲述数据的采集流程.
docker
docker-compose
apache kafka服务
数据采集流程
数据的产生使用cadvisor采集容器的监控数据并将数据传输到Kafka.
数据的传输链路是这样: Cadvisor->Kafka->Fluentd->elasticsearch
每一个服务都可以横向扩展,添加服务到日志系统中.
				Kafka 日志存储
在进行详解之前，我想先声明一下，本次我们进行讲解说明的是 Kafka 消息存储的信息文件内容，不是所谓的 Kafka 服务器运行产生的日志文件，这一点希望大家清楚。
Kafka 消息是以主题为单位进行归类，各个主题之间是彼此独立的，互不影响。每个主题又可以分为一个或多个分区。每个分区各自存在一个记录消息数据的日志文件。也就是该文要着重关注的内容。我们根据如下的图进行进一步说明...
				log.retention.hours 和 log.retention.ms 这两个配置项设置 Kafka 数据最大保留时间，默认为一周
log.retention.bytes 设置 Kafka 每个分区保存数据的最大容量
如果同时指定了 log.retention.hours 和 log.retention.bytes，那么只要任一条件得到满足，消息就会被删除
例如，如果 log.retention.hours 设置为 24 (一天)，log.retention.bytes 设置为 1000000000
				关于 Kafka 拉取超时时间的设置，合适的数值取决于您的应用程序的具体需求和环境。
通常来说，拉取超时时间设置较短的值能够更快地发现消息的不可用性，但会增加客户端的网络开销和 CPU 负载。相反，设置较长的值可以减少客户端的网络开销和 CPU 负载，但需要更长的时间来发现消息的不可用性。
因此，您可以根据您的具体需求来设置拉取超时时间。如果您需要快速发现消息的不可用性，可以设置较短的拉取超时时间；如果对系统资源使用效率更加关注，则可以设置较长的拉取超时时间。