问题1：Filebeat启动后Kibana日志延迟最高30分钟，是否正常？ #

这绝对不属于正常现象，6.2.4版本的ELK栈即便在资源一般的虚拟机上，端到端延迟也应该控制在几秒到几分钟内，30分钟的延迟说明链路中某环节出现了积压或阻塞。常见原因和排查方向：

• Filebeat侧：检查Filebeat日志确认是否有发送阻塞、重试失败的记录，比如Logstash连接超时。可以查看filebeat.yml中的output.logstash配置，是否设置了过大的bulk_max_size或过小的flush_interval，导致日志攒够批量才发送（默认flush_interval是1秒，bulk_max_size是2048，若日志量极小，可能会攒一段时间，但不会到30分钟）。
• Logstash侧：查看Logstash的日志文件，检查是否有过滤规则报错、Elasticsearch写入超时的情况。另外，Logstash的pipeline.batch.size（默认125）和pipeline.batch.delay（默认5ms）如果设置不合理，也会导致处理延迟；如果启用了持久化队列，队列积压也会让后续日志延迟写入ES。
• Elasticsearch侧：执行curl -XGET 'http://<ES地址>:9200/_cat/indices?v'查看目标索引的refresh_interval，若被修改为30分钟（比如为了优化写入性能手动调整），会导致ES每隔30分钟才把内存中的数据刷到磁盘，Kibana自然查不到最新数据。同时检查ES的堆内存配置（jvm.options中的Xms/Xmx），若内存不足会严重拖慢写入速度；另外查看_cat/thread_pool?v，看bulk线程池是否有积压。
• 资源瓶颈：部署ELK的虚拟机CPU、内存或磁盘IO不足，会导致ES、Logstash无法及时处理请求，形成链式延迟。

问题2：关闭Kibana自动刷新15分钟后重新开启，预期表现是什么？ #

a) 是否会快速加载15分钟日志并实时展示新日志？ #

是的，这是正常预期的表现。Kibana的自动刷新只是定时向Elasticsearch发起查询，查询范围是你设定的“最近15分钟”。当你关闭自动刷新时，Elasticsearch一直在正常接收并存储日志，所以重新开启自动刷新后，Kibana会立即拉取这15分钟内所有符合条件的日志，之后每5秒查询一次最新的日志，实现“补全历史+实时更新”的效果。

b) 是否会持续存在15分钟延迟？ #

不会。Kibana的刷新设置本身不会导致持续延迟，若出现这种情况，说明Elasticsearch的写入本身就存在15分钟的延迟（比如前面问题1中提到的ES刷新间隔过大、Logstash队列积压等），或者Kibana的索引模式时间字段配置错误——比如把非时间字段设为了时间过滤字段，导致Kibana查询的时间范围和实际日志时间不匹配。

问题3：停止Filebeat后Kibana仍刷新日志约1小时，甚至展示旧日志？ #

这种情况主要和链路中的缓冲机制有关，也可能涉及日志时间戳解析问题：

1. Logstash队列缓冲：Logstash默认使用内存队列，若配置了queue.type: persisted（持久化队列），会把接收到的日志存储在磁盘队列中。即使Filebeat停止，Logstash会继续从队列中读取日志并发送给Elasticsearch，这个过程的时长取决于队列中的日志量和ES的处理速度，若队列较大，持续1小时是可能的。你可以通过curl -XGET 'http://<Logstash地址>:9600/_node/stats/queue'查看队列的积压情况。

2. Filebeat关闭前的缓冲：Filebeat有shutdown_timeout配置（默认5秒），若停止Filebeat时缓冲中还有未发送的日志，可能会因为超时未完成发送而残留，但这个时间一般不会太长，若要优化可以适当调大该参数。

3. 旧日志展示的原因：如果看到Kibana在无新日志时展示旧日志，大概率是日志时间戳解析错误。比如Logstash没有用date插件正确提取日志本身的时间戳，导致Elasticsearch用接收日志的时间作为@timestamp字段存储。当这些“旧内容但新时间戳”的日志被索引后，会出现在Kibana“最近15分钟”的查询结果中，让你误以为是旧日志被重复展示。

解决方案：

• 若想停止Filebeat后立即终止日志流入，需先停止Logstash（确保队列处理完成），或者调整Logstash队列配置减小缓冲规模；
• 检查并修复Logstash的date插件配置，确保@timestamp字段对应日志本身的生成时间，而非ES的接收时间；
• 调整Filebeat的shutdown_timeout为10-30秒，让它在停止前完成缓冲日志的发送。

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