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