每個系統都有日誌，當系統出現問題時，需要通過日誌解決問題 當系統機器比較少時，登陸到伺服器上查看即可滿足 當系統機器規模巨大，登陸到機器上查看幾乎不現實 當然即使是機器規模不大，一個系統通常也會涉及到多種語言的開發，那麼問題來了，每次系統出問題了，如何能夠迅速查問題? 好一點的情況可能是python ...
每個系統都有日誌，當系統出現問題時，需要通過日誌解決問題 當系統機器比較少時，登陸到伺服器上查看即可滿足 當系統機器規模巨大，登陸到機器上查看幾乎不現實 當然即使是機器規模不大，一個系統通常也會涉及到多種語言的開發，那麼問題來了，每次系統出問題了，如何能夠迅速查問題? 好一點的情況可能是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。
