引言
好久沒寫分佈式系列的文章了，最近剛好有個朋友給我留言，想看這方面的知識。其實這方面的知識，網上各種技術峯會的資料一抓一大把。博主也是湊合着寫寫。感覺自己也寫不出什麼新意，大家也湊合看看。
日誌系統的必要性?
我15年實習的時候那會，給某國企做開發。不怕大家笑話，生產上就兩臺機器。那會定位生產問題，就是連上一臺機器，然後用使用 grep / sed / awk 等 Linux 腳本工具去日誌裏查找故障原因。如果發現不在這臺機器上，就去另一臺機器上查日誌。有經歷過上述步驟的童鞋們，請握個抓！
然而，當你的生產上是一個有幾千臺機器的集羣呢？你要如何定位生產問題呢？又或者，你哪天有這麼一個需求，你需要收集某個時間段內的應用日誌，你應該如何做？
爲了解決上述問題，我們就需要將日誌集中化管理。這樣做，可以提高我們的診斷效率。同時也有利於我們全面理解系統。
正文
組件簡介
這裏大概介紹一下ELK組件在搭建日誌系統過程中所扮演的角色，這邊瞭解一下即可，具體的會在後文進行說明。
大家應該都知道ELK指的是:（Elasticsearch＋Logstash＋Kibana）。其中
-
Logstash:負責採集日誌 -
Elasticsearch:負責存儲最終數據、建立索引、提供搜索功能 -
Kibana：負責提供可視化界面
好了，知道上面的定義，可以開始講演進過程了
實習版
OK，這版算是Demo版，各位開發可以在自己電腦上搭建練練手，如下圖所示。
這種架構下我們把 Logstash實例與Elasticsearch實例直接相連，主要就是圖一個簡單。我們的程序App將日誌寫入Log，然後Logstash將Log讀出，進行過濾，寫入Elasticsearch。最後瀏覽器訪問Kibana，提供一個可視化輸出。
缺點
該版的缺點主要是兩個
-
在大併發情況下，日誌傳輸峯值比較大。如果直接寫入ES,ES的HTTP API處理能力有限，在日誌寫入頻繁的情況下可能會超時、丟失，所以需要一個緩衝中間件。
-
注意了，Logstash將Log讀出、過濾、輸出都是在應用服務器上進行的，這勢必會造成服務器上佔用系統資源較高，性能不佳，需要進行拆分。
於是，我們的初級版誕生了！
初級版
在這版中，加入一個緩衝中間件。另外對Logstash拆分爲Shipper和Indexer。先說一下，LogStash自身沒有什麼角色，只是根據不同的功能、不同的配置給出不同的稱呼而已。Shipper來進行日誌收集，Indexer從緩衝中間件接收日誌，過濾輸出到Elasticsearch。具體如下圖所示
說一下，這個緩衝中間件的選擇。
大家會發現，早期的博客，都是推薦使用redis。因爲這是ELK Stack 官網建議使用 Redis 來做消息隊列，但是很多大佬已經通過實踐證明使用Kafka更加優秀。原因如下:
-
Redis無法保證消息的可靠性，這點Kafka可以做到 -
Kafka的吞吐量和集羣模式都比Redis更優秀 -
Redis受限於機器內存，當內存達到Max，數據就會拋棄。當然，你可以說我們可以加大內存啊？但是，在Redis中內存越大，觸發持久化的操作阻塞主線程的時間越長。相比之下，Kafka的數據是堆積在硬盤中，不存在這個問題。
因此，綜上所述，這個緩存中間件，我們選擇使用Kafka。
缺點
主要缺點還是兩個
-
Logstash Shipper是jvm跑的，非常佔用JAVA內存！ 。據《ELK系統使用filebeat替代logstash進行日誌採集》這篇文章說明，8線程8GB內存下，Logstash常駐內存660M（JAVA）。因此，這麼一個巨無霸部署在應用服務器端就不大合適了，我們需要一個更加輕量級的日誌採集組件。 -
上述架構如果部署成集羣，所有業務放在一個大集羣中相互影響。一個業務系統出問題了，就會拖垮整個日誌系統。因此，需要進行業務隔離！
中級版
這版呢，引入組件Filebeat。當年，Logstash的作者用golang寫了一個功能較少但是資源消耗也小的輕量級的Logstash-forwarder。後來加入Elasticsearch後，以logstash-forwarder爲基礎，研發了一個新項目就叫Filebeat。
相比於Logstash，Filebeat更輕量，佔用資源更少，所佔系統的 CPU 和內存幾乎可以忽略不計。畢竟人家只是一個二進制文件。那麼，這一版的架構圖如下，我直接畫集羣版
至於這個Tribe Node，中文翻譯爲部落結點，它是一個特殊的客戶端，它可以連接多個集羣，在所有連接的集羣上執行搜索和其他操作。在這裏呢，負責將請求路由到正確的後端ES集羣上。
缺點
這套架構的缺點在於對日誌沒有進行冷熱分離。因爲我們一般來說，對一個禮拜內的日誌，查詢的最多。以7天作爲界限，區分冷熱數據，可以大大的優化查詢速度。
高級版
這一版，我們對數據進行冷熱分離。每個業務準備兩個Elasticsearch集羣，可以理解爲冷熱集羣。7天以內的數據，存入熱集羣，以SSD存儲索引。超過7天，就進入冷集羣，以SATA存儲索引。這麼一改動，性能又得到提升，這一版架構圖如下(爲了方便畫圖，我只畫了兩個業務Elasticsearch集羣)
隱患
這個高級版，非要說有什麼隱患，就是敏感數據沒有進行處理，就直接寫入日誌了。關於這點，其實現在JAVA這邊，現成的日誌組件，比如log4j都有提供這種日誌過濾功能，可以將敏感信息進行脫敏後，再記錄日誌。