貝聊ELK實戰

你們好，我是貝聊的運維工程師馬鐵軍，咱們貝聊剛上了ELK系統，這裏針對以前的實戰過程做一個概括總結，跟各位分享一下:

1、部署ELK的背景

以前公司沒有一套統一的日誌收集方案

1. 大部分開發人員都有相應服務器的登錄權限，增長管理成本

2. 開發人員查詢日誌的時若是命令使用不當有可能形成內存耗盡、誤刪除等問題，給服務器帶來很多安全隱患

3. 現有的日誌統計，調整至關不便，實效性差

4. 重要業務都有冗餘機器，日誌分佈在幾臺機器上，查找不便

若是有日誌收集方案:

1. 開發人員不須要服務器權限也能快捷的查找問題

2. 能夠根據業務須要從各個維度分析日誌並展示

3. 日誌集中實時收集，查詢問題不影響服務器正常運行

2、技術選型

一般一套日誌管理體系須要以下幾個階段的工做：

1.日誌的採集

2.日誌的彙總與過濾

3.日誌的存儲

4.日誌的分析與查詢

ELK技術棧(即Logstash + ElasticSearch + Kibana)屬於業界已經應用比較普遍且成熟的開源方案，這套一站式解決方案基本上能夠知足大部分企業對日誌管理體系的需求。咱們即選擇ELK做爲日誌收集方案，其架構以下：

這種架構有以下優勢：

一、 使用filebeat收集日誌，減小應用服務器的壓力

二、中間層使用kafka作消息隊列。防止數據丟失同時也能起到削峯填谷的做用

三、Logstash根據需求過濾處理數據

四、ES兩個數據節點一個主節點緩解壓力

五、ElastAlert插件定時去查詢ES裏面的數據，根據用戶配置實時告警

六、方便擴容

3、遇到的問題及解決方案：

一、日誌中的時間爲系統時間不爲日誌輸出的時間。這是因爲logstash在寫入ES的時候默認會生成寫入時間點的時間戳@timestamp，kibana默認以@timestamp爲時間過濾字段致使的

二、因爲時區致使日誌8小時的時差。引發這個問題主要是因爲ELK各組件對時間的處理是基於「數據的存儲和顯示相分離」的設計原則，只要把表示絕對時間的時間戳存儲數據庫，在顯示的時候根據用戶設置的時區格式化爲正確的時間。因此在logstash寫入ES時存儲爲UTC時間，因爲中國是東八區，因此會比日誌時間晚8個小時，而kibana是從ES讀出UTC時間後，經過瀏覽器獲取當時時區，在UTC時間的基礎上加上瀏覽器時區偏移值，再展示出來。當logstash沒有正確設置時區時即會致使這個問題

如上兩個問題以經過在logstash filter階段使用date插件處理

date {

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

target => "@timestamp"

timezone => "+08:00"

}

三、_dateparsefailure失敗。這是因爲時間匹配失敗，仔細檢查date插件的math看是否與日誌時間格式對上

四、Grokparsefailure失敗。這是因爲日誌消息正則匹配失敗可經過以下網站調試：grokdebug.herokuapp.com/

五、logstash重啓消費kafka。Logstash默認會把全部的配置文件整合爲同一個配置文件，因爲咱們java日誌分爲dubbo服務和web服務，在filebeat收集的時候我把它們放在一個kafka topic中，致使在logstash這邊配置了兩個文件同時消費同一個topic，引起這個問題

六、索引默認以logstash開頭。ES使用默認索引模板都是以logstash開頭。若是需自定義則須要經過ES接口配置新的索引模板

七、ES數據查詢緩慢，剛開始時2個數據節點又爲主節點，致使CPU負載太高。後面把主節點分離出來。同時使用，數據保存15天，熱索引7天。加快查詢速度。同時修改默認的分片數和副本數

八、Logstash負載太高，logstash最耗負載的就是grok，因此把nginx日誌改成json格式，其次一些固定格式的日誌使用dissect插件進行切割，這是5.x版本中新插件，能很大程度上下降logstash負載

4、部署以後成效

一、系統故障報警更及時，之前在系統出現故障時須要等到URL監控、或者數據庫監控報警才能發現問題，這兩個監控粒度較大，每每發現故障時已經很嚴重了。部署ElastAlert監控以後能實時監控nginx日誌的狀態碼，當某個錯誤狀態碼在1分鐘內達到500個就告警。及時有效的告警服務給故障排查留出了寶貴的時間，以便在最短的時間內解決問題，把影響降到最小。

二、能夠實時快速的查詢每一個接口的響應時間。優化響應慢的接口，提升系統服務質量

三、故障排查更迅速，當碰到有異常流量時及時過濾出異常IP\UserAgent，添加防火牆，減小系統安全事故

四、回收開發人員服務器上的權限，減小誤操做的可能

五、每週生成質量報表，統計每一個項目每週的ERROR、WARN日誌

六、每一個項目按需求建好visualize實現日誌可視化，分析各項目運行狀態更方便快捷

5、總結

一、在部署過程當中或多或少會碰到各類故障，排查故障時需仔細觀察日誌，找到引起故障的關鍵字，再根據關鍵字作有針對性的排查。其次要仔細觀察配置文件瞭解各配置的原理，上下文關係。

二、實施項目前要充分調研項目的可行性

三、在部署完畢以後能夠根據實際狀況進行調優，使系統處於最佳的運行狀態