我們公司處理用戶報來的問題時，一般都是值班人員先根據(jù)用戶提供的相關信息在elk中搜索相關服務日志 (包括nginx 日志，各個app服務日志)，然后分析問題原因。不過最近kibana總是查不到數(shù)據(jù)，返回結(jié)果為空，并且沒有任何新數(shù)據(jù)顯示。我們運維人員只好手動查詢了幾個問題。?
閑下來之后就開始排查問題了。
排查問題步驟
1. 查看ES集群狀態(tài)?
? ? ?通過kopf界面看到ES集群狀態(tài)是健康的
2. 查看數(shù)據(jù)是不是在ES集群中
? ? ?在kopf中監(jiān)控doc的總數(shù)，數(shù)值確實是實時增加的，通過api也查看了最新數(shù)據(jù)，數(shù)據(jù)格式和數(shù)值都是對的
3. 重啟大法
? ? 上面2個步驟沒有任何發(fā)現(xiàn)后，只好先重啟kibana, ES了， 結(jié)果還是一樣，kibana返回為空。
4. 從kibana發(fā)出請求分析
? ? 在kibana上查詢了各個時間段的數(shù)據(jù)，發(fā)現(xiàn)nginx的日志8點之前的數(shù)據(jù)是存在的，之后就是一片空白，從es日志中發(fā)現(xiàn)8點的時候新創(chuàng)建了index,logstash-2016.06.03, 從kibana發(fā)出的請求elasticsearch/logstash-*/_field_stats?level=indices應答中發(fā)現(xiàn)timestame,min_value和max_value顯示的都是UTC時間，懷疑是沒有配置為當前時區(qū)，后來經(jīng)確認kibana默認會和瀏覽器時區(qū)保持一致，ES后端也是用的UTC時間，所以才會有8點新建的index logstash-2016.06.03.?
這個時候就懷疑index的mapping有問題了。
5. 分析index mapping和 index template
? ? 在kopf中把logstash-2016.06.02的mapping和logstash-2016.06.03新生成的index mapping做了對比，發(fā)現(xiàn)mapping發(fā)送了變化，配置發(fā)送了變更。經(jīng)過對比排查和確認是@timestamp字段定義發(fā)生了變化，從
"@timestamp": {
"format": "strict_date_optional_time||epoch_millis",
"type": "date"
}變成了
"@timestamp": {
"index": "not_analyzed",
"type": "date"
},?
猜測是因為調(diào)優(yōu)把很多不查詢的字段改為了not_analyzed, 最好把老的mapping更新到了index template, 然后刪除了已有的index logstash-2017.06.03 (因為當前的index日志不多，重要性沒那么高，所以沒有做alias來reindex), 之后新的index template創(chuàng)建的index logstash-2017.06.03。 之后再kibana里重現(xiàn)添加了這個index pattern, 數(shù)據(jù)正常顯示了。
分析和總結(jié)為什么@timestamp這個字段不能改為not_analyzed
kibana都是基于時間來查詢過濾數(shù)據(jù)的，如果@timestamp不做分詞的話，kibana的各種時間段查詢肯定不會生效的，必須把各個時間段分詞后才能比較查出結(jié)果。
經(jīng)過這次事件后，我們發(fā)現(xiàn)index template的備份是必要的，要不然排查追溯問題很不方便。
