引言
好久沒寫分布式系列的文章了，最近剛好有個朋友給我留言，想看這方面的知識。其實這方面的知識，網上各種技術峰會的資料一抓一大把。博主也是湊合着寫寫。感覺自己也寫不出什么新意，大家也湊合看看。
日志系統的必要性?
我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都有提供這種日志過濾功能，可以將敏感信息進行脫敏后，再記錄日志。