Kibana Discover日志存在延迟，请求原因排查与分析

从你描述的情况和给出的日志、配置来看，VM时间不同步是导致日志延迟的核心原因，再加上Logstash没有正确解析日志自带的时间字段，进一步放大了这个问题，具体分析如下：

1. 时间同步问题的直接影响 #

你提到两台VM均采用PDT时区但时间不一致，而且偏差还在持续增加。从日志数据就能看出明显的时间错位：

• 应用端最新日志的time字段是2018-05-17T06:06:44.365607578Z（UTC时间），对应的PDT时间应该是2018-05-16 23:06:44
• Kibana中显示的@timestamp是May 16th 2018, 17:58:09.408，这比应用日志的PDT时间慢了5小时左右，正好对应两台VM的时间差

因为Logstash默认会用自身所在VM的系统时间来生成@timestamp字段，而不是日志实际产生的时间。如果Logstash所在VM的时间比应用VM慢5小时，那它接收应用日志时，就会给日志打上一个“慢5小时”的时间戳，导致在Kibana里看起来日志延迟了5小时，而且随着两台VM的时间差越来越大，这个延迟也会持续增加。

2. Logstash配置的缺失加剧了问题 #

你的Logstash filter配置里没有添加date插件，这意味着你没有告诉Logstash去解析日志自带的time字段，而是完全依赖Logstash的系统时间生成@timestamp。如果配置了date插件，即使两台VM有小的时间偏差，日志的时间戳也会基于实际产生的时间，而不是接收时间，能大幅缓解这类问题。

解决步骤 #

第一步：修复VM时间同步问题 #

优先解决两台VM的时间不一致问题，配置NTP服务让它们同步到同一个时间源（比如公共NTP服务器），确保PDT时区下的系统时间完全一致，并且不会再出现偏差持续增加的情况。

第二步：修改Logstash Filter配置，添加时间解析 #

在你的02-beats-input.conf的filter部分，添加date插件来解析日志里的time字段，将其设置为@timestamp：

filter {
  # 保留你现有的其他filter规则...

  # 解析日志自带的ISO8601格式时间，替换默认的@timestamp
  date {
    match => ["time", "ISO8601"]
    target => "@timestamp"
    remove_field => ["time"] # 可选：解析完成后移除原time字段，减少冗余
  }
}

这个配置会告诉Logstash：从日志的time字段读取实际的日志生成时间，并用这个时间替换默认的@timestamp，这样Kibana里显示的时间就会和日志实际产生的时间一致，不再受Logstash所在VM系统时间的影响。

第三步：验证修复效果 #

完成上述两步后，观察Kibana Discover中的日志：

• 新日志的@timestamp应该和应用端日志的time字段（转换为PDT后）完全一致
• 之前的延迟现象会消失，也不会再出现延迟持续增加的情况

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