- 每個系統都有日志，當系統出現問題時，需要通過日志解決問題
- 當系統機器比較少時，登陸到伺服器上檢視即可滿足
- 當系統機器規模巨大，登陸到機器上檢視幾乎不現實
當然即使是機器規模不大，一個系統通常也會涉及到多種語言的開發，拿我們公司來說，底層是通過c++開發的，而也業務應用層是通過Python開發的，并且即使是C++也分了很多級别應用，python這邊同樣也是有多個應用，那麼問題來了，每次系統出問題了，如何能夠迅速查問題? 好一點的情況可能是python應用層查日志發現是系統底層處理異常了，于是又叫C++同僚來查，如果C++這邊能夠迅速定位出錯誤告知python層這邊還好，如果錯誤好排查，可能就是各個開發層的都在一起查到底是哪裡引起的。當然可能這樣說比較籠統，但是卻引發了一個問題：
- 當系統出現問題後，如何根據日志迅速的定位問題出在一個應用層？
- 在平常的工作中如何根據日志分析出一個請求到系統主要在那個應用層耗時較大？
- 在平常的工作中如何擷取一個請求到達系統後在各個層測日志彙總？
針對以上問題，我們想要實作的一個解決方案是：
- 把機器上的日志實時收集，統一的存儲到中心系統
- 然後再對這些日志建立索引，通過搜尋即可以找到對應日志
- 通過提供界面友好的web界面，通過web即可以完成日志搜尋
關于實作這個系統時可能會面臨的問題：
- 實時日志量非常大，每天幾十億條(雖然現在我們公司的系統還沒達到這個級别)
- 日志準實時收集，延遲控制在分鐘級别
- 能夠水準可擴充
關于日志收集系統，業界的解決方案是ELK
ELK的解決方案是通用的一套解決方案，是以不免就會産生以下的幾個問題：
- 運維成本高，每增加一個日志收集，都需要手動修改配置
- 監控缺失，無法準确擷取logstash的狀态
- 無法做定制化開發以及維護
針對這種情況，其實我們想要的系統是agent可以動态的擷取某個伺服器我們需要監控哪些日志
以及那些日志我們需要收集，并且當我們需要收集日志的伺服器下線了，我們可以動态的停止收集
當然這些實作的效果最終也是通過web界面呈現。
回到頂部
日志收集系統設計
主要的架構圖為
關于各個元件的說明：
- Log Agent，日志收集用戶端，用來收集伺服器上的日志
- Kafka，高吞吐量的分布式隊列，linkin開發，apache頂級開源項目
- ES，elasticsearch，開源的搜尋引擎，提供基于http restful的web接口
- Hadoop，分布式計算架構，能夠對大量資料進行分布式處理的平台
回到頂部
關于Kakfa的介紹
Apache Kafka是一個分布式釋出 - 訂閱消息系統和一個強大的隊列，可以處理大量的資料，并使您能夠将消息從一個端點傳遞到另一個端點。 Kafka适合離線和線上消息消費。 Kafka消息保留在磁盤上，并在群集内複制以防止資料丢失。 Kafka建構在ZooKeeper同步服務之上。 它與Apache Storm和Spark非常好地內建，用于實時流式資料分析。
注：這裡關于Kafka并不會介紹太多，隻是對基本的内容和應用場景的說明，畢竟展開來說，這裡的知識也是費非常多的
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