目錄:
GitHub項目地址：https://github.com/PlutoaCharon/Golang_logCollect⭐
Golang實戰之海量日誌收集系統（二）收集應用程序日誌到Kafka中
Golang實戰之海量日誌收集系統（三）簡單版本logAgent的實現
Golang實戰之海量日誌收集系統（四）etcd介紹與使用etcd獲取配置信息
Golang實戰之海量日誌收集系統（五）根據etcd配置項創建多個tailTask
Golang實戰之海量日誌收集系統（六）監視etcd配置項的變更
Golang實戰之海量日誌收集系統（七）logTransfer之從kafka中獲取日誌信息
Golang實戰之海量日誌收集系統（八）logTransfer之將日誌入庫到Elasticsearch並通過Kibana進行展示
項目背景
項目架構圖：
- 每個系統都有日誌，當系統出現問題時，需要通過日誌解決問題
- 當系統機器比較少時，登陸到服務器上查看即可滿足
- 當系統機器規模巨大，登陸到機器上查看幾乎不現實
每個業務系統都有自己的⽇志，當業務系統出現問題時，需要通過查找⽇志信息來定位和解決問題。 當業務系統服務器⽐較少時，登陸到服務器上查看即可滿⾜。但當系統機器規模巨⼤，登陸到服務器上查看⼏乎不現實（分佈式的系統，⼀個系統部署在⼗⼏甚至幾十臺服務器上）
平常我們在進行業務開發時常常不免遇到下面幾個問題:
- 當系統出現問題後，如何根據日誌迅速的定位問題出在一個應用層？
- 在平常的工作中如何根據日誌分析出一個請求到系統主要在那個應用層耗時較大？
- 在平常的工作中如何獲取一個請求到達系統後在各個層測日誌彙總？
針對以上問題，我們想要實現的一個解決方案是：
- 把機器上的日誌實時收集，統一的存儲到中心繫統
- 然後再對這些日誌建立索引，通過搜索即可以找到對應日誌
- 通過提供界面友好的web界面，通過web即可以完成日誌搜索
關於實現這個系統時可能會面臨的問題：
- 實時日誌量非常大，每天幾十億條
- 日誌準實時收集，延遲控制在分鐘級別
- 能夠水平可擴展
業界方案
有早期的ELK到現在的EFK。ELK在每臺服務器上部署logstash，比較重量級，所以演化成客戶端部署filebeat的EFK，由filebeat收集向logstash中寫數據，最後落地到elasticsearch，通過kibana界面進行日誌檢索。
優缺點
優點：現成的解決方案，直接拿過來用，能夠實現日誌收集與檢索。
缺點：
- 運維成本⾼，每增加⼀個⽇志收集項，都需要⼿動修改配置
- 監控缺失，⽆法準確獲取logstash的狀態。⽆法做到定製化開發與維護
- ⽆法做到定製化開發與維護
日誌收集系統設計
各個組件說明：
Log Agent，日誌收集客戶端，用來收集服務器上的日誌
Kafka，高吞吐量的分佈式隊列
Elasticsearch，開源的搜索引擎，提供基於http restful的web接口
Flink,Spark，分佈式計算框架，能夠對大量數據進行分佈式處理的平臺
關於Kakfa的介紹
-
Kafka是一個分佈式發佈 - 訂閱消息系統和一個強大的隊列，可以處理大量的數據，並使您能夠將消息從一個端點傳遞到另一個端點。 -
Kafka適合離線和在線消息消費。 -
Kafka消息保留在磁盤上，並在羣集內複製以防止數據丟失。 -
Kafka構建在ZooKeeper同步服務之上。 它與Flink和Spark非常好的集成，用於實時流式數據分析。
Kafka中有幾個基本的消息術語：
- Kafka將消息以topic爲單位進行歸納。
- 將向Kafka topic發佈消息的程序成爲producers.
- 將預訂topics並消費消息的程序成爲consumer.
- Kafka以集羣的方式運行，可以由一個或多個服務組成，每個服務叫做一個broker
Kafka的優點：
- 可靠性 - Kafka是分佈式，分區，複製和容錯的。
- 可擴展性 - Kafka消息傳遞系統輕鬆縮放，無需停機。
- 耐用性 - Kafka使用分佈式提交日誌，這意味着消息會盡可能快地保留在磁盤上，因此它是持久的。
- 性能 - Kafka對於發佈和訂閱消息都具有高吞吐量。 即使存儲了許多TB的消息，它也保持穩定的性能。
- Kafka非常快，並保證零停機和零數據丟失。
Kafka的應用場景：
-
異步處理, 把非關鍵流程異步化，提高系統的響應時間和健壯性
![在這裏插入圖片描述]()
![在這裏插入圖片描述]()
-
應用解耦,通過消息隊列
![在這裏插入圖片描述]()
![在這裏插入圖片描述]()
-
流量削峯
![在這裏插入圖片描述]()
ZooKeeper介紹
ZooKeeper是一種分佈式協調服務，用於管理大型主機。在分佈式環境中協調和管理服務是一個複雜的過程。ZooKeeper通過其簡單的架構和API解決了這個問題。ZooKeeper允許開發人員專注於核心應用程序邏輯，而不必擔心應用程序的分佈式特性。
Apache ZooKeeper是由集羣（節點組）使用的一種服務，用於在自身之間協調，並通過穩健的同步技術維護共享數據。ZooKeeper本身是一個分佈式應用程序，爲寫入分佈式應用程序提供服務。
ZooKeeper主要包含幾下幾個組件：
- Client（客戶端）：我們的分佈式應用集羣中的一個節點，從服務器訪問信息。對於特定的時間間隔，每個客戶端向服務器發送消息以使服務器知道客戶端是活躍的。類似地，當客戶端連接時，服務器發送確認碼。如果連接的服務器沒有響應，客戶端會自動將消息重定向到另一個服務器。
- Server（服務器）：服務器，我們的ZooKeeper總體中的一個節點，爲客戶端提供所有的服務。向客戶端發送確認碼以告知服務器是活躍的。
- Ensemble：ZooKeeper服務器組。形成ensemble所需的最小節點數爲3。
- Leader： 服務器節點，如果任何連接的節點失敗，則執行自動恢復。Leader在服務啓動時被選舉。
- Follower：跟隨leader指令的服務器節點。
- ZooKeeper的應用場景：
服務註冊&服務發現
配置中心
- 分佈式鎖
Zookeeper是強一致的多個客戶端同時在Zookeeper上創建相同znode，只有一個創建成功
關於Log Agent
主要實現的功能是：
類似於我們在linux下通過tail的方法讀日誌文件，講讀取的內容發給Kafka
我們這裏的tailf是可以動態變化的，當配置文件發生變化時，可以通知我們程序自動增加需要增加的配置文件
tailf去獲取相應的日誌併發給kafka producer
主要由一下幾部目錄組成：
Kafka
tailf
configlog
該項目中Zookeeper與Kafka可以安裝在Liunx環境中使用遠程連接,也可以在Windows本地安裝連接使用
具體安裝參考我的這篇博客: Windows10安裝運行Kafka2.1.0與Zookeeper3.4.14