分散式之elk日誌架構的演進
引言
好久沒寫分散式系列的文章了，最近剛好有個朋友給我留言，想看這方面的知識。其實這方面的知識，網上各種技術峰會的資料一抓一大把。博主也是湊合著寫寫。感覺自己也寫不出什麼新意，大家也湊合看看。
日誌系統的必要性?
我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記憶體！ 。據 ofollow,noindex" target="_blank">《ELK系統使用filebeat替代logstash進行日誌採集》 這篇文章說明，8執行緒8GB記憶體下，Logstash常駐記憶體660M（JAVA）。因此，這麼一個巨無霸部署在應用伺服器端就不大合適了，我們需要一個更加輕量級的日誌採集元件。 - 上述架構如果部署成叢集，所有業務放在一個大叢集中相互影響。一個業務系統出問題了，就會拖垮整個日誌系統。因此，需要進行業務隔離！
中級版
這版呢，引入元件Filebeat。當年，Logstash的作者用golang寫了一個功能較少但是資源消耗也小的輕量級的Logstash-forwarder。後來加入Elasticsearch後，以logstash-forwarder為基礎，研發了一個新專案就叫Filebeat。
相比於Logstash，Filebeat更輕量，佔用資源更少，所佔系統的 CPU 和記憶體幾乎可以忽略不計。畢竟人家只是一個二進位制檔案。那麼，這一版的架構圖如下，我直接畫叢集版
從上圖可以看到，Elasticsearch根據業務部了3個叢集，他們之間相互獨立。避免出現，一個業務拖垮了Elasticsearch叢集，整個日誌系統就一起宕機的情況。而且，從運維角度來說，這種架構運維起來也更加方便。
至於這個 Tribe Node ，中文翻譯為部落結點，它是一個特殊的客戶端，它可以連線多個叢集，在所有連線的叢集上執行搜尋和其他操作。在這裡呢，負責將請求路由到正確的後端ES叢集上。
缺點
這套架構的缺點在於對日誌沒有進行冷熱分離。因為我們一般來說，對一個禮拜內的日誌，查詢的最多。以7天作為界限，區分冷熱資料，可以大大的優化查詢速度。
