解决logstash创建es索引默认使用@timestamp的UTC时间所导致的时区问题

场景：

有一个用户行为日志的统计，其使用logstash过滤后放到es里面。

脚本是这样

每天记录通过一个field，指定其index名称

放到es指定的index中

问题：

2019.09.17的index

2019.09.16的index 出现了发生在9月17日的document

 

原因：

两个问题：

问题1：

决定数据进入到哪个index中的决定因素是@timestamp，@timestamp是日志上报的时间

logstash将东8区的时间，错误转换为了UTC时间，减去了8个小时，从而导致数据被路由到了9月16日的index中

问题2：

需要补充一个基础知识：logstash中@timestamp作用

In the absence of this filter, logstash will choose a timestamp based on the first time it sees the event (at input time), if the timestamp is not already set in the event. For example, with file input, the timestamp is set to the time of each read.

• 如果在event中设置了@timestamp这个字段，那么logstash就会复用这个字段

• 如果event中没有设置，那么就会将时间设置为logstash读取到这个event的时间

我们这里并没有特别处理@timestamp，所以其就是日志上报到logstash的时间

这里包含一个业务知识：我们的上报并不是即时上报的，会发生延时上报的情况，日志真实发生的时候logdatetime与@timestamp并不相同

原因是：

我们的kibana时间filter使用的是生产环境中的实际日志产生的时间：logdatetime

而决定数据进入到哪个index中的决定因素是@timestamp，@timestamp是日志上报的时间

这两个错误叠加，导致问题

解决方案：

很多的解决方案是说 用自己的某个时间字段覆盖掉@timestamp这个字段，但是我并不想这么做，因为@timestamp记录的是这个事件初次被logstash读取的时间（可以认为是上报的时间）

要不就把@timestamp这个字段转换为，比如说reportTimestamp字段，然后把logDatetime字段转换为@timestamp字段，这样就会实现这一天的点击行为都会进入到同一个物理index中。

add_field => {"reportTimestamp" => "%{@timestamp}"}

最后的效果：

可以看到真实发生的时间 与 上报的时间是一致的，并且进入到正确的index中，与日志记录保持一致

而上报的时间reportTimestamp被单独记录下来

这样就会实现这一天的点击行为都会进入到同一个物理index中，对于一天的用户行为统计，可以避免es的跨index查询