現在使用的比較常用的日志分析系統有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