Es+kafka搭建日誌存儲查詢系統（設計）

 如今使用的比較經常使用的日誌分析系統有Splunk和Elk，Splunk功能齊全，處理能力強，可是是商用項目，並且收費高。Elk則是Splunk項目的一個開源實現，Elk是ElasticSearch（Es）、Logstash、Kibana上個項目結合。Es就是基於Lucene的存儲，索引的搜索引擎；logstash是提供輸入輸出及轉化處理插件的日誌標準化管道；Kibana提供可視化和查詢統計的用戶界面。每每這些開源項目並非適合每個公司的業務，業務不一樣，對開源項目擴展也就不一樣，logstash進行日誌採集時，在Agent端並不適合作數據清洗，數據清洗每每是常常變化的，並且Agent通常佔用的資源必需要受到必定限制不然會影響業務系統。咱們能夠將日誌的採集採用一些開源系統從新進行組合，由於日誌採集的業務特性，能夠採用Es+kafka進行初步的存儲查詢。首先以Http協議收集日誌爲例，

 

將整個日誌存儲查詢整體分爲四個層處理：

第一層：日誌採集層；

主要處理日誌採集的過程，針對生成的日誌不一樣，大致上分紅三大部分：

（1）、日誌經過Http協議彙總到服務器端，通常是Web端，或者IOS、Android移動端經過HTTP 請求上報日誌，這部分日誌採集的agent暴露在公網上，可能會存在一些惡意上報垃圾日誌，這部分日誌是須要進行權限驗證的，例如：在上報的日誌中帶上Token的驗證，驗證不成功直接丟棄，成功則將log存入到kafka對應的topic中。

（2）、服務器上的文本日誌，這部分日誌通常是業務系統存儲的log文件，因爲存在的是服務器端，通常不須要進行token驗證，就能夠直接採用logstash或者rsyslog進行彙總到kafka中去。

（3）、非文本日誌，須要本身進行開發的自定義Agent 採集相關日誌發送到kafka中，如監控某一個 radis、mysql等組件。此類日誌和（2）相同，通常不是暴露在公網上，不須要進行token驗證。

第二層：kafka

（1）、kafka的主要做用一個方面主要是爲防止採集量大於日誌清洗、存儲的能力，這樣會形成日誌系統處理不及時，或者形成系統宕機，引發日誌丟失。kafka是Apache開源的Hadoop生態圈中的分佈式消息隊列，其擴展性、和性能是很是強大的。加入消息隊列在遇到日誌高峯期，不能及時處理的日誌存儲在kafka中，不影響後面的日誌清洗的系統，同時經過分析kafka 中日誌隊列的處理狀況可以，對日誌清洗層能力進行擴展和縮減。

（2）、另外一方面就是方便系統解耦 ，使用kafka也方便擴展，若是要對日誌進行一些實時統計處理，則採用Storm-kafka直接訂閱相關的topic就可以將日誌數據導入到Storm集羣中進行實時統計分析。

第三層：日誌清洗層；

將全部的日誌清洗和統計的邏輯歸於這一層進行處理。

第四層：日誌存儲層；

將日誌存入到Es進行索引創建和查詢。

 

環境搭建及相關例子：

官方文檔：http://kafka.apache.org/090/documentation.html#quickstart

同時也能夠採用CDH、Ambari等集羣管理工具安裝 kafka，這裏再也不贅述，Ambari離線安裝文檔：http://pan.baidu.com/s/1i5NrrSh。

storm實時處理例子：https://github.com/barrysun/storm-ml/tree/master/logmapping-storm-kafka