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