ELK是ElasticSearch，LogStash以及Kibana三个产品的首字母缩写。是可以和商业产品 Splunk 相媲美开源项目。

2013 年，Logstash 被 Elasticsearch 公司收购，ELK stack 正式成为官方用语。Elasticsearch是近两年最受关注的大数据项目之一，三次融资已经超过一亿美元。

ElasticSearch是一个基于全文检索引擎lucene实现的一个面向文档的schema free的数据库。所有对数据库的配置、监控及操作都通过Restful接口完成。数据格式为json。默认支持节点自动发现，数据自动复制，自动分布扩展，自动负载均衡。适合处理最大千万级别的数据的检索。处理效率非常高。可以理解为elasticSearch是一个在lucene基础上增加了restful接口及分布式技术的整合。

Logstash是一个对文件日志或者syslog日志以及其他各种类型的输入数据流进行解码，过滤，转换并转换为其他类型的数据流的软件，最常见的用法是将系统日志分析，结构化处理后倒入到ElasticSearch中。当然logstash也可以独立的完成很多日志/事件处理的工作，并不是必须要和ElasticSearch配合使用。

Kibana是一个通过Restful接口对ElasticSearch数据库进行检索，通过HTML5形式以柱状图，饼图，线图，地理位置分布图以及表格等形式展示数据的软件。

这三者结合在一起能实现将海量的日志进行分析处理，并最终以丰富图表的形式进行展现。这三个软件虽然经常在一起使用，但是也可以分别单独工作。

实际使用中logstash相对于fluentd几乎完败，其所有的有点fluentd都具备。而且随着libbeat的发展，很多情况下消息都不需要经过logstash转换。所以对于logstash的使用可以简化和慎重考虑。可能的话应该考虑使用fluentd代替。

如果存在更大的数据量，例如大于千万级，ELK可以和Hadoop进行整合，实现对更大数据量的支持。

ELK一直在进行改进，除了上述的对日志的处理，通过使用libbeat的go语言架构还能类似top命令的图形显示以及通过网络流量分析实现应用，例如mysql,http的图形显示。

通过ELK我们可以实现以下目的：

l. 海量数据的分析及展示：目前正在进行的数据分析系统就存在原始数据非结构化，数据量大，展示角度多样等特点就非常适合ELK。

2. 文档检索系统：对于海量文档的全文检索及管理系统，非常适合。

3. 实时监控系统：对于大量监控指标，需要实时监控，对界面美观有要求的业务监控系统来说，也非常适合ELK。例如和ganglia的整合。而且有些展示方式是仙人掌不可能实现的，例如饼图，地理位置图，表格等！通过topbeat和packagebeat可以直接实现操作系统以及应用的监控。

4. 集中日志系统：虽然我们使用了syslog-ng来实现集中日志处理，但是存在数据丢失以及不便于检索的问题。对于复杂的应用，不同类型的日志分布在不同的服务器上，对于业务流程分析过程来说，通过ELK可以将各种日志整合在一起，集中分析。便于发现问题之间的关联关系。

Index：存储数据的逻辑区域，类似关系型数据库中的database，是文档的命名空间。如下图的湖蓝色部分所示，Index为twitter。

Type：类似关系型数据库中的Table，是包含一系列field的json数据。储存一系列类似的field。如下图的黄色部分所示，Type为tweet。不同document里面同名的field一定要是相同类型的。

Document：存储的实体数据，类似关系型数据库中的Row，是具体的包含一组filed的资料。如下图橙色部分所示，包含user,post_data,message三个field。

Field：即关系型数据库中Column， Document的一个组成部分，有两个部分组成，name和value。如下图紫色部分所示 post_date及其具体的值就是一个field。

Mapping：存储field的相关映射信息，不同document type会有不同的mapping。

Term：不可分割的单词，搜索最小单元。不同的分析器对同样的内容的分析结果是不同的。也就得到不同的term。

Token：一个Term呈现方式，包含这个Term的内容，在文档中的起始位置，以及类型。

Node：对应这关系型数据库中的数据库实例。

Cluster：由多个node组成的一组服务实例。

Shard：关系型数据库中无此概念，是Lucene搜索的最小单元。一个index可能会存在于多个shards，不同shards可能在不同nodes。一个lucene index在es中我们称为一个shard，而es中的index则是一系列shard。当es执行search操作，会将请求发送到这个index包含的所有shard上去，然后将没一个shard上的执行结果搜集起来作为最终的结果。shard的个数在创建索引之后不能改变！

Replica：shard的备份，有一个primary shard，其余的叫做replica shards。Elasticsearch采用的是Push Replication模式，当你往 master主分片上面索引一个文档，该分片会复制该文档(document)到剩下的所有 replica副本分片中，这些分片也会索引这个文档

文档的录入时，Elasticsearch通过对docid进行hash来确定其放在哪个shard上面，然后在shard上面进行索引存储。

当进行查询时，如果提供了查询的DocID，Elasticsearch通过hash就知道Doc存在哪个shard上面，再通过routing table查询就知道再哪个node上面，让后去node上面去取就好了。如果不提供DocID,那么Elasticsearch会在该Index（indics）shards所在的所有node上执行搜索，然后返回搜索结果，由coordinating node gather之后返回给用户。每个node都可以接收请求，会自动判断是否可以本地处理还是需要其他node协助处理。

Logstash是用jruby编写的一个收集，分析，处理日志或事件的软件。

每位系统管理员都肯定写过很多类似这样的命令：cat randdata | awk '{print $2}' | sort | uniq -c | tee sortdata。这个管道符 | 可以算是 Linux 世界最伟大的发明之一(另一个是“一切皆文件”)。

Logstash 就像管道符一样！你输入(就像命令行的 cat )数据，然后处理过滤(就像 awk 或者 uniq 之类)数据，最后输出(就像 tee )到其他地方。

Logstash 不只是一个input | filter | output 的数据流，而是一个 input | decode | filter | encode | output 的数据流！codec 就是用来 decode、encode 数据的。

codec 的引入，使得 logstash 可以更好的与其他有自定义数据格式的运维产品共存，比如 ganglia、graphite、fluent、netflow、collectd，以及使用 msgpack、json、edn 等通用数据格式的其他产品等。

丰富的插件，让logstash可以方便的与各种系统进行整合。

Logstash的配置文件是通过一系列的input{}，filter{}，以及output{}区块，以及if等条件判断语句组成的。每个区块中都应该根据需要配置不同的插件。

Logstash的配置文件可以包含在多个文件中，一般位于/etc/logstash/conf.d目录下，文件名应该以.conf为扩展名。每个文件都可以是某个类型日志处理的完整过程或者一个片段。

具体如何配置，应该参考最新的官方文档，https://www.elastic.co/guide/en/logstash/current/index.html，所以请确认不要参考早期文档。