大家好，我是貝聊的運維工程師馬鐵軍，我們貝聊剛上了ELK系統，這裡針對之前的實戰過程作一個歸納總結，跟各位分享一下:
一、部署ELK的背景
之前公司沒有一套統一的日誌收集方案
1. 大部分開發人員都有相應伺服器的登陸許可權，增加管理成本
2. 開發人員查詢日誌的時如果命令使用不當有可能造成記憶體耗盡、誤刪除等問題，給伺服器帶來不少安全隱患
3. 現有的日誌統計，調整相當不便，實效性差
4. 重要業務都有冗餘機器，日誌分佈在幾臺機器上，查詢不便
如果有日誌收集方案:
1. 開發人員不需要伺服器許可權也能快捷的查詢問題
2. 可以根據業務需要從各個維度分析日誌並展現
3. 日誌集中實時收集，查詢問題不影響伺服器正常執行
二、技術選型
通常一套日誌管理體系需要如下幾個階段的工作：
1.日誌的採集
2.日誌的彙總與過濾
3.日誌的儲存
4.日誌的分析與查詢
ELK技術棧(即Logstash + ElasticSearch + Kibana)屬於業界已經應用比較廣泛且成熟的開源方案，這套一站式解決方案基本上可以滿足大部分企業對日誌管理體系的需求。我們即選擇ELK作為日誌收集方案，其架構如下：
這種架構有如下優點：
1、 使用filebeat收集日誌，減少應用伺服器的壓力
2、中間層使用kafka做訊息佇列。防止資料丟失同時也能起到削峰填谷的作用
3、Logstash根據需求過濾處理資料
4、ES兩個資料節點一個主節點緩解壓力
5、ElastAlert外掛定時去查詢ES裡面的資料，根據使用者配置實時告警
6、方便擴容
三、遇到的問題及解決方案：
1、日誌中的時間為系統時間不為日誌輸出的時間。這是由於logstash在寫入ES的時候預設會生成寫入時間點的時間戳@timestamp，kibana預設以@timestamp為時間過濾欄位導致的
2、由於時區導致日誌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"
}
3、_dateparsefailure失敗。這是由於時間匹配失敗，仔細檢查date外掛的math看是否與日誌時間格式對上
4、Grokparsefailure失敗。這是由於日誌訊息正則匹配失敗可通過如下網站除錯：grokdebug.herokuapp.com/
5、logstash重啟消費kafka。Logstash預設會把所有的配置檔案整合為同一個配置檔案，由於我們java日誌分為dubbo服務和web服務，在filebeat收集的時候我把它們放在一個kafka topic中，導致在logstash這邊配置了兩個檔案同時消費同一個topic，引發這個問題
6、索引預設以logstash開頭。ES使用預設索引模板都是以logstash開頭。如果需自定義則需要通過ES介面配置新的索引模板
7、ES資料查詢緩慢，剛開始時2個資料節點又為主節點，導致CPU負載過高。後面把主節點分離出來。同時使用，資料儲存15天，熱索引7天。加快查詢速度。同時修改預設的分片數和副本數
8、Logstash負載過高，logstash最耗負載的就是grok，所以把nginx日誌改為json格式，其次一些固定格式的日誌使用dissect外掛進行切割，這是5.x版本中新外掛，能很大程度上降低logstash負載
四、部署之後成效
1、系統故障報警更及時，以前在系統出現故障時需要等到URL監控、或者資料庫監控報警才能發現問題，這兩個監控粒度較大，往往發現故障時已經很嚴重了。部署ElastAlert監控之後能實時監控nginx日誌的狀態碼，當某個錯誤狀態碼在1分鐘內達到500個就告警。及時有效的告警服務給故障排查留出了寶貴的時間，以便在最短的時間內解決問題，把影響降到最小。
2、可以實時快速的查詢每個介面的響應時間。優化響應慢的介面，提高系統服務質量
3、故障排查更迅速，當碰到有異常流量時及時過濾出異常IP\UserAgent，新增防火牆，減少系統安全事故
4、回收開發人員伺服器上的許可權，減少誤操作的可能
5、每週生成質量報表，統計每個專案每週的ERROR、WARN日誌
6、每個專案按需求建好visualize實現日誌視覺化，分析各專案執行狀態更方便快捷
五、總結
1、在部署過程中或多或少會碰到各種故障，排查故障時需仔細觀察日誌，找到引發故障的關鍵字，再根據關鍵字做有針對性的排查。其次要仔細觀察配置檔案瞭解各配置的原理，上下文關係。
2、實施專案前要充分調研專案的可行性
3、在部署完畢之後可以根據實際情況進行調優，使系統處於最佳的執行狀態