Go實現海量日誌收集系統(一)

天天學習一點點 編程PDF電子書免費下載: http://www.shitanlife.com/code

 

項目背景

  • 每一個系統都有日誌,當系統出現問題時,須要經過日誌解決問題
  • 當系統機器比較少時,登錄到服務器上查看便可知足
  • 當系統機器規模巨大,登錄到機器上查看幾乎不現實

固然即便是機器規模不大,一個系統一般也會涉及到多種語言的開發,拿咱們公司來講,底層是經過c++開發的,而也業務應用層是經過Python開發的,而且即便是C++也分了不少級別應用,python這邊一樣也是有多個應用,那麼問題來了,每次系統出問題了,如何可以迅速查問題? 好一點的狀況多是python應用層查日誌發現是系統底層處理異常了,因而又叫C++同事來查,若是C++這邊可以迅速定位出錯誤告知python層這邊還好,若是錯誤好排查,可能就是各個開發層的都在一塊兒查究竟是哪裏引發的。固然可能這樣說比較籠統,可是卻引起了一個問題:node

  • 當系統出現問題後,如何根據日誌迅速的定位問題出在一個應用層?
  • 在日常的工做中如何根據日誌分析出一個請求到系統主要在那個應用層耗時較大?
  • 在日常的工做中如何獲取一個請求到達系統後在各個層測日誌彙總?

針對以上問題,咱們想要實現的一個解決方案是:python

  • 把機器上的日誌實時收集,統一的存儲到中心繫統
  • 而後再對這些日誌創建索引,經過搜索便可以找到對應日誌
  • 經過提供界面友好的web界面,經過web便可以完成日誌搜索

關於實現這個系統時可能會面臨的問題:linux

  • 實時日誌量很是大,天天幾十億條(雖然如今咱們公司的系統還沒達到這個級別)
  • 日誌準實時收集,延遲控制在分鐘級別
  • 可以水平可擴展

關於日誌收集系統,業界的解決方案是ELKc++

ELK的解決方案是通用的一套解決方案,因此難免就會產生如下的幾個問題:web

  • 運維成本高,每增長一個日誌收集,都須要手動修改配置
  • 監控缺失,沒法準確獲取logstash的狀態
  • 沒法作定製化開發以及維護

針對這種狀況,其實咱們想要的系統是agent能夠動態的獲取某個服務器咱們須要監控哪些日誌
以及那些日誌咱們須要收集,而且當咱們須要收集日誌的服務器下線了,咱們能夠動態的中止收集
固然這些實現的效果最終也是經過web界面呈現。apache

日誌收集系統設計

主要的架構圖爲編程

關於各個組件的說明:服務器

  • Log Agent,日誌收集客戶端,用來收集服務器上的日誌
  • Kafka,高吞吐量的分佈式隊列,linkin開發,apache頂級開源項目
  • ES,elasticsearch,開源的搜索引擎,提供基於http restful的web接口
  • Hadoop,分佈式計算框架,可以對大量數據進行分佈式處理的平臺

關於Kakfa的介紹

Apache Kafka是一個分佈式發佈 - 訂閱消息系統和一個強大的隊列,能夠處理大量的數據,並使您可以將消息從一個端點傳遞到另外一個端點。 Kafka適合離線和在線消息消費。 Kafka消息保留在磁盤上,並在羣集內複製以防止數據丟失。 Kafka構建在ZooKeeper同步服務之上。 它與Apache Storm和Spark很是好地集成,用於實時流式數據分析。restful

注:這裏關於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

 

小結

以上是對整個要開發的系統的一個總的歸納,以及架構的一個構建,而且各個組件的實現,接下來會一個一個實現每一個部分的功能,下一篇文章會實現上述組件中log Agent的開發

 

全部的努力都值得期許,每一份夢想都應該灌溉!
 
 
 

天天學習一點點 編程PDF電子書免費下載: http://www.shitanlife.com/code

相關文章
相關標籤/搜索