前言
由於接入日誌平臺的項目越來越多，ES不堪重負，各項系統性能持續在高位，影響讀寫性能。原有1.0架構無法滿足大量的日誌寫入ES，所以調整架構，引入2.0版本，提高吞吐量，增加日誌緩存層及日誌處理層，滿足日誌大批量多索引查詢的需求。
1.0和2.0架構對比
1.0架構如下：
在應用服務器上部署filebeat收集日誌，同時對日誌格式進行處理，然後將日誌直接寫入ES；ES爲三節點架構。
缺點：1.由於需要進行日誌處理，filebeat在應用服務器上需要進行大量計算，導致CPU佔用較多，搶佔了應用本身的資源。
2.filebeat不經過緩存直接寫入ES集羣，造成隊列變大，影響日誌寫入的時效性。
3.三臺ES集羣無法同時承受大量的讀寫，導致查詢變慢，甚至出現超時。
4.由於filebeat直連ES，如果ES集羣節點出現，將導致日誌寫入失敗，等到集羣恢復後，部分日誌無法在ES進行查詢。
綜上所述，我們升級架構，增加緩存層和處理層，對日誌進行緩存，同時進行ES集羣的冷熱分離，解決上面出現的問題。
2.0架構如下：
將filebeat收集的日誌，存儲到kafka進行緩存，保留三天數據；然後由logstash從kafka中實時讀取數據進行處理，再將處理完的數據寫入ES；ES集羣由3臺server升級爲8臺，進行冷熱分離，熱區只保留5天數據，超過5天的數據通過ES的生命週期管理(ILM)，自動轉移到冷區並通過腳本將索引關閉，冷區server配置較低，主要用於存儲及方便一些歷史查詢需要。由於熱區索引控制，分片數減少，同時採用SSD盤，讀寫性能提升明顯，滿足業務及測試的查詢需求。
未來3.0架構調整方向思考
1.降低成本冷區存儲由硬盤改用OSS歸檔存儲，配置存儲策略定期進行清理。
2.增加日誌分析及告警功能。
3.如果日誌量持續增大考慮將kafka單機改爲集羣，同時拆分logstash爲單獨機器。
4.增加熱區server數量，做讀寫分離。