【原創】分佈式之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內存！ 。據《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天做爲界限，區分冷熱數據，能夠大大的優化查詢速度。

高級版

這一版，咱們對數據進行冷熱分離。每一個業務準備兩個Elasticsearch集羣，能夠理解爲冷熱集羣。7天之內的數據，存入熱集羣，以SSD存儲索引。超過7天，就進入冷集羣，以SATA存儲索引。這麼一改動，性能又獲得提高，這一版架構圖以下(爲了方便畫圖，我只畫了兩個業務Elasticsearch集羣)

隱患
這個高級版，非要說有什麼隱患，就是敏感數據沒有進行處理，就直接寫入日誌了。關於這點，其實如今JAVA這邊，現成的日誌組件，好比log4j都有提供這種日誌過濾功能，能夠將敏感信息進行脫敏後，再記錄日誌。