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架构的演变之路，写的比较粗糙，基础理论知识请自行学习。本系列博文适合有一定基础
的同仁阅读参考。