场景：
有一个用户行为日志的统计，其使用logstash过滤后放到es里面。
脚本是这样
每天记录加入一个field，指定其位置
根据这个filed，放到es指定的index中
问题：
2019.09.17的index
2019.09.16的index
显然遇到了时区转换问题
原因：
logstash创建es索引默认使用@timestamp的UTC时间
......
可以看到决定数据进入到哪个index中的决定因素是@timestamp
而这个@timestamp的时间在logstash看来是东八区时间
其将其转换为UTC，然后去放到index中
所以9-17日的index的@timestamp是2019年9月17 08:00:00到9月18 08:00
实际上从logstash的角度，其在9-17日的index中应该存的是
UTC时间 2019年9月17 00:00:00到9月17 23:59:59的数据
而@timestamp实际上是东八区时间，从而出现了时区转换的问题
解决方案：
如何解决这个问题呢？
那就是告诉logstash，这个@timestamp实际上的东8区的时间就是UTC时间，不需要做时区转换（trick logstash 欺骗logstash）
或者是自己给logstash认为的UTC时间，再多加上8个小时
采用多加上8个小时的方法
这个logDateTime字段记录的是用户行为发生的时间，其为UNIX_MS
另外，我想记录@timestamp这个字段，因为我想知道这条记录logstash所处理的时间
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.
通过先下面的脚本进行记录
add_field => {"reportTimestamp" => "%{@timestamp}"}
最后的效果：
这样就会实现这一天的点击行为都会进入到同一个物理index中，对于一天的用户行为统计，可以避免es的跨shard查询
参考：
