引言

好久沒寫分散式系列的文章了，最近剛好有個朋友給我留言，想看這方面的知識。其實這方面的知識，網上各種技術峰會的資料一抓一大把。博主也是湊合著寫寫。感覺自己也寫不出什麼新意，大家也湊合看看。

日誌系統的必要性?

我15年實習的時候那會，給某國企做開發。不怕大家笑話，生產上就兩臺機器。那會定位生產問題，就是連上一臺機器，然後用使用 grep / sed / awk 等 Linux 指令碼工具去日誌裡查詢故障原因。如果發現不在這臺機器上，就去另一臺機器上查日誌。有經歷過上述步驟的童鞋們，請握個抓！
然而，當你的生產上是一個有幾千臺機器的叢集呢？你要如何定位生產問題呢？又或者，你哪天有這麼一個需求，你需要收集某個時間段內的應用日誌，你應該如何做？
為了解決上述問題，我們就需要將日誌集中化管理。這樣做，可以提高我們的診斷效率。同時也有利於我們全面理解系統。

正文

元件簡介

這裡大概介紹一下ELK元件在搭建日誌系統過程中所扮演的角色，這邊瞭解一下即可，具體的會在後文進行說明。
大家應該都知道ELK指的是:（Elasticsearch＋Logstash＋Kibana）。其中

• Logstash:負責採集日誌
• Elasticsearch:負責儲存最終資料、建立索引、提供搜尋功能
• Kibana：負責提供視覺化介面

好了，知道上面的定義，可以開始講演進過程了

實習版

OK，這版算是Demo版，各位開發可以在自己電腦上搭建練練手，如下圖所示。

這種架構下我們把 Logstash例項與Elasticsearch例項直接相連，主要就是圖一個簡單。我們的程式App將日誌寫入Log，然後Logstash將Log讀出，進行過濾，寫入Elasticsearch

• 在大併發情況下，日誌傳輸峰值比較大。如果直接寫入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都有提供這種日誌過濾功能，可以將敏感資訊進行脫敏後，再記錄日誌。

作者：孤獨煙 出處： http://rjzheng.cnblogs.com/

鄭州不孕不育檢查

鄭州不孕不育

鄭州最好的不孕不育醫院

鄭州不孕不育