golang日誌收集方案之ELK

每一個系統都有日誌，當系統出現問題時，須要經過日誌解決問題

當系統機器比較少時，登錄到服務器上查看便可知足

當系統機器規模巨大，登錄到機器上查看幾乎不現實

固然即便是機器規模不大，一個系統一般也會涉及到多種語言的開發，那麼問題來了，每次系統出問題了，如何可以迅速查問題?

好一點的狀況多是python應用層查日誌發現是系統底層處理異常了，因而又叫C++同事來查，若是C++這邊可以迅速定位出錯誤告知python層這邊還好，若是錯誤好排查，

可能就是各個開發層的都在一塊兒查究竟是哪裏引發的。固然可能這樣說比較籠統，可是卻引起了一個問題：

 

當系統出現問題後，如何根據日誌迅速的定位問題出在一個應用層？

在日常的工做中如何根據日誌分析出一個請求到系統主要在那個應用層耗時較大？

在日常的工做中如何獲取一個請求到達系統後在各個層測日誌彙總？

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

 

把機器上的日誌實時收集，統一的存儲到中心繫統

而後再對這些日誌創建索引，經過搜索便可以找到對應日誌

經過提供界面友好的web界面，經過web便可以完成日誌搜索

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

 

實時日誌量很是大，天天幾十億條(雖然如今咱們公司的系統還沒達到這個級別)

日誌準實時收集，延遲控制在分鐘級別

可以水平可擴展

關於日誌收集系統，業界的解決方案是ELK

對於日誌來講，最多見的需求就是收集、存儲、查詢、展現，開源社區正好有相對應的開源項目：logstash（收集）、elasticsearch（存儲+搜索）、kibana（展現），

咱們將這三個組合起來的技術稱之爲ELKStack，因此說ELKStack指的是Elasticsearch、Logstash、Kibana技術棧的結合，由這三個軟件及其相關的組件能夠打造大規模日誌實時處理系統。

 

實際使用中，在Logstash上加了一層Beat,

Beats是用於單用途數據託運人的平臺。它們以輕量級代理的形式安裝，並未來自成百上千臺機器的數據發送到Logstash或Elasticsearch。

（畫外音：通俗地理解，就是採集數據，並上報到Logstash或Elasticsearch）

 

elasticsearch下載地址：https://www.elastic.co/downloads/elasticsearch

logstash下載地址：https://www.elastic.co/downloads/logstash

kibana下載地址：https://www.elastic.co/downloads/kibana

filebeat下載地址：https://www.elastic.co/products/beats/filebeat

 

也可直接docker安裝ELK鏡像

docker run -p 5313:5044 -p 5314:5601 -p 5315:9200 -p 5316:9300 \
-e ES_JAVA_OPTS="-Xms256m -Xmx512m" \
-e ES_MAX_MEM=1024m \
-v /elk:/var/lib/elasticsearch -d -i -t --restart always --name=elk01 sebp/elk

我在項目中用uber的zap處理日誌，而後用filebeat轉發至logstash，數據存儲在es，最後展現在kibana。