場景：
有一個用戶行爲日誌的統計，其使用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查詢