ELK架构的演变

ELK的名称是由最原始架构的三个组件的首字母组合而来，即E（lasticsearch）L（ogstash）K（ibana），

固然ELK演变至今天已经再也不只用三个组件了。最原初的三个组件都是基于java语言研发的，相对来讲比较

重量级，正常运行所需服务器配置要求较高。想在生产中使用ELK作日志分析的朋友须要作好资源准备。

要想上手ELK，必须对ELK的架构及运行原理作透彻的理解，废话很少说，先来看ELK架构的演变之路。

ELK原始架构（三层架构）：

第一层：logstash：收集日志+解析日志+发送给elasticsearch

第二层：elasticsearch：索引日志+存储日志+提供检索API

第三层：kibana：从elasticsearch中抽取数据进行展现+生成图表

logstash主要有三大功能模块：input+filter+output（也即：收集日志+解析日志+发送日志）

input：能够直接从文件中抓取，也能够从队列中抓取，也能接收日志生产工具的输出（好比java的log4j输出）

filter：对无结构化的数据进行解析处理，生成半结构化数据，filter支持较多插件，比较典型的有grok、date、

goeip、kv、json、mutate

output：能够输出到elasticsearch，也能够输出到消息队列（如redis、kafka），也能输出给监控系统（如zabbix）

elasticsearch：主要有三大功能，索引数据+存储数据+提供检索API

基于Lucene的二次封装，提供了REST API的操做接口

引用wiki原话对Lucene的描述以下：

Lucene是一套用于全文检索和搜索的开放源代码程序库，由Apache软件基金会支持和提供。

Lucene提供了一个简单却强大的应用程序接口，可以作全文索引和搜索，在Java开发环境里

Lucene是一个成熟的免费开放源代码工具；就其自己而论，

Lucene是如今而且是这几年，最受欢迎的免费Java信息检索程序库。

Solr是使用Lucene的企业搜索服务器，亦由Apache软件基金会所研发。

kibana：从elasticsearch中抽取数据进行展现+生成图表

Kibana自带Node.js Web服务器，无需额外代码或额外基础设施。

若是想安全套件的话，能够购买官方的企业版本，若是以为基础功可以用

也可使用nginx反代并启用basic authentication也不错

引用aws对kibana的描述：

开源数据可视化和挖掘工具

能够用于日志和时间序列分析、应用程序监控和运营智能使用案例。

Kibana与Elasticsearch这种常见的分析和搜索引擎紧密集成，

成为了将Elasticsearch中存储的数据可视化时的默认选择。

Kibana之因此受欢迎还由于其易于使用的强大功能，

如柱状图、线形图、饼状图、热区图和内置地理空间支持。

因为logstash基于java语言研发，若是运行在业务服务器上会有较大的资源损耗，因而就有了把logstash

的功能进行拆解，也就是在原始架构了多一层，造成了如下架构：

四层架构：

第一层：lostash-agent：收集日志+发送给logstash-indexer，不作日志解析

第二层：logstash-indexer：解析从logstash-agent传送过来的日志+发送给elasticsearch

第三层：elasticsearch：索引日志+存储日志+提供检索API

第四层：kibana：从elasticsearch中抽取数据进行展现+生成图表

因为logstash自己是不存储日志自己的，若是多台服务器同时使用logstash-agent向logstash-indexer

发送大量日志数据，对logstash-indexer来讲压力会很是大，而且极有可能出现数据丢失的状况，因此有

给logstash-agent和logstash-indexer之间添加一层消息队列需求，因而在上面四层的基础上，又多出了

一层，造成了比较完善的架构：

五层架构：

第一层：lostash-agent：收集日志+发送给message-queue，不作日志解析

第二层：message-queue：专业缓存logstash-agent发送过来的大量日志数据（经常使用队列：kafka/redis……）

第三层：logstash-indexer：从message-queue中取出数据并进行解析，解析完成后发送给elasticsearch

第四层：elasticsearch：索引日志+存储日志+提供检索API

第五层：kibana：从elasticsearch中抽取数据进行展现+生成图表

第二层引用了消息队列，须要咱们考虑消息队列的选型问题：

须要咱们考虑的是若是前端全部的logstash-agent送往消息队列的数据量不是特殊大的状况，能够先用redis

作为消息队列，但须要明白redis默认是基于内存的消息队列，若是内存不足够，但便会致使内存充满后的消息

将会被redis自动丢弃，也就会带来数据丢失问题。其二，redis的是基于分布式pub/sub插件来实现，消息不可

重复消费。

若是对于以上方案不太满意，能够考虑使用kafka来作分布式的消息队列，kafka对于并发数据流很是大的场景

可以有很好的支持，kafka默认使用磁盘存储队列数据，所能容纳的数据量以及数据的可行性显然比redis要强大。

其次，kafka的消息支持重复消费。但kafka自身就是分布式的架构，因此须要有分布式集群管理工具，默认使用

同一流派的zookeeper，此二者都是基于java语言研发的，安装时须要安装jdk环境。

因为logstash始终是比较重量级，因而就有了filebeat替换logstash-agent收集日志，因此上面的层次没变

只是第一层的实现方式变了，因此最终的架构演变以下：

最流行架构：

第一层：filebeat：收集日志+发送给message-queue，不提供日志解析功能

第二层：message-queue：专业缓存logstash-agent发送过来的大量日志数据（经常使用队列：kafka/redis……）

第三层：logstash-indexer：从message-queue中取出数据并进行解析，解析完成后发送给elasticsearch

第四层：elasticsearch：索引日志+存储日志+提供检索API

第五层：kibana：从elasticsearch中抽取数据进行展现+生成图表

filebeat：基于go语言研发，相对logstash来讲要轻量的太多，作为agent端安装在各个业务服务器上不用担忧占用

太多的服务器资源。

如今的企业大多使用的是深化到最后的这一套架构，相比之下，最后的这套五层架构也是至关成熟及稳定了，若是有想

上日志系统的朋友建议能够考虑使用filebeat+kafka（zookeeper）+logstash+elasticsearch+kibana这套架构。

毕竟考虑到后期后的扩容以及优化操做都比较有利。

这是给你们简单的分享了一下ELK架构的演变之路，写的比较粗糙，基础理论知识请自行学习。本系列博文适合有必定基础

的同仁阅读参考。