集中日誌系統ELK

做用

之前都是登錄到每一個機器去看日誌，特別是一個服務有多個機器集羣部署，還要下載多個機器的日誌(運維下載日誌，而後給開發排查問題)，如今elk是集中式日誌系統，全部的項目和項目集羣都在一個日誌系統裏，並且能夠搜索。

---

界面

組成

L是收集日誌，還有解析日誌

E是搜索引擎，就是ElasticSearch

K就是界面

流程

原始日誌(L的客戶端)——收集和解析日誌(L的服務器端)——搜索引擎(E)——界面展現(K)

解釋

1.收集日誌和解析日誌
收集日誌就是客戶端到服務器，就是把L客戶端安裝到部署項目的機器，而後讀原始日誌文件，再寫到L的服務器端。這是收集日誌，就是：原始日誌文件——L的客戶端——L的服務器。

L的服務器還要解析日誌，主要是解析爲固定的幾個字段，好比時間、IP(哪一個機器的日誌)、日誌自己的內容、項目名字(哪一個項目的日誌)。這幾個固定字段是搜索引擎須要的字段。

2.搜索引擎
剛纔解析以後的字段，再寫給搜索引擎。

3.界面

filebeat

爲何要用filebeat，由於L的客戶端性能很差，影響部署項目的機器，因此換了filebeat做爲L的客戶端，做用和L的客戶端同樣，都是收集日誌，本質就是先讀原始日誌文件，而後再寫到L的服務器。這就是filebeat的做用，對部署項目的機器無影響。

kafka

爲何要用kafka，由於日誌產生和日誌消費的速度不匹配，還有因爲網絡緣由，可能會致使數據丟失，因此纔要加消息中間件，由於消息中間件能夠緩存海量數據，而且數據不會丟失(丟失可能性極小，不會大量丟失數據)。

架構圖的演變

只有ELK

L的客戶端沒有使用filebeat。

---

換了filebeat

L的客戶端換成了filebeat。

---

加了消息中間件

---

雙層L

從左往右看

從右往左看

第一層L做用只是分流，第二層L做用是解析爲固定幾個字段。

參考

https://mp.weixin.qq.com/s/F8...
https://www.cnblogs.com/wangx...

https://blog.qiniu.com/archiv...

https://jusene.github.io/2018...