預設情況下ELK收集到的日誌在kibana上展示出來的時間戳和日誌的生成時間是不一致的，或許很多朋友來說和日誌生成的時間相差無幾，

那我只能說，你的日誌系統可能資源比較充足，處理的比較及時，所以你看到的日誌收集時間戳和日誌產生時間戳是相差無幾的效果，

但如果是想匯入歷史日誌資料進行相應的分析，這個時候恐怕你的日誌系統處理速度再塊也無法解決日誌收集時間和日誌生成時間相差太

遠的問題。如果不進行處理，你在kibana上所看到的時間序列根本不是日誌生成的時間戳，所以說如何使用日誌的生成時間戳去替換掉存

儲在Elasticsearch中的時間戳也即@timestamp欄位就顯得尤為重要了。場景搞明白了，重要的就是如何實現了！

看過很多部落格，最後發現是把自己給繞進去了，為什麼這麼說了，很多人都只是想下文一樣，貼上了自己的配置，別的什麼也沒多說。

filter {

    if [type] == "nginx-log" {

        grok {

            match => { "message" => "%{HOSTNAME:logserver} %{PATH:logpath} %{NGINX_ACCESS_LOG}" }

            match => { "message" => "%{HOSTNAME:logserver} %{PATH:logpath} %{NGINX_ERROR_LOG}" }

            remove_field  => "message"

        }

date {

    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]

}

}

}

對於本文來其實要講的是如下段落

date {

    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]

}

容易出現問題的是很多人在上文使用grok解析日誌時都沒有使用timestamp這個欄位名稱，他也直接照抄，那你可以想一下，date這一部分

是基於上一個流程的結果進行的，所以會報錯"date plug-in parsing exception"。

但也有人說了，我有timestamp這個欄位，還是沒有解析正確，那很大的可能就是"dd/MMM/yyyy:HH:mm:ss Z"這個欄位的配置沒理解正確，

筆者當初也是一樣，誤以為這個欄位是設定格式化後的日期時間顯示格式，但最後查詢了很多資料之後，終於看到有人詳說了，這個是自己的

日誌檔案裡面日期日間的格式，也就是說"dd/MMM/yyyy:HH:mm:ss Z"這個欄位是要看源日誌裡面的日期時間格式後在此配置的，並非所有的

日誌裡面的日期時間都是一樣的，所以需要根據不同的檔案日誌設定為不同的配置，當然如果在同一類日誌檔案裡面有多種日期時間格式，是

可以，用空格+逗號配置成可以匹配多個日期時間格式的。

由此以來，我們就可以很方便的根據使用者的訪問時間直接去查詢該時間段內的相應日誌，這是非常有用的。

除此之外，如果想匯入歷史日誌進行相應的分析，這個時間戳能以之前的真實生成時間進行索引也是相當有益的。