简介
ELK 是 Elasticsearch、Logstash、Kibana 三大开源框架首字母大写简称。市面上也被成为 Elastic Stack。
Elasticsearch
Elasticsearch 是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能；是一套开放 REST 和 JAVA API 等结构提供高效搜索功能，可扩展的分布式系统。它构建于 Apache Lucene 搜索引擎库之上。
Logstash
Logstash 是一个用来搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和 JMX，它能够以多种方式输出数据，包括电子邮件、websockets 和 Elasticsearch。
Kibana
Kibana 是一个基于 Web 的图形界面，用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据。它利用Elasticsearch 的 REST 接口来检索数据，不仅允许用户创建他们自己的数据的定制仪表板视图，还允许他们以特殊的方式查询和过滤数据。
通过上面对 ELK 简单的介绍，我们知道了 ELK 字面意义包含的每个开源框架的功能。市面上很多开发只要提到 ELK 都能够一致说出它是一个日志分析架构技术栈总称，但实际上 ELK 不仅仅适用于日志分析，它还可以支持其它任何数据分析和收集的场景，日志分析和收集只是更具有代表性。并非唯一性。
为什么使用ELK
一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
在过往的单体应用时代，我们所有组件都部署到一台服务器中，那时建立集中式日志收集系统的需求可能并没有那么强烈，我们只需要登录到一台服务器通过 shell 命令就可以很方便的查看系统日志，并快速定位问题。随着互联网的发展，互联网已经全面渗入到生活的各个领域，使用互联网的用户量也越来越多，单体应用已不能够支持庞大的用户的并发量，尤其像中国这种人口大国。那么将单体应用进行拆分，通过水平扩展来支持庞大用户的使用迫在眉睫，微服务概念就是在类似这样的阶段诞生，在微服务盛行的互联网技术时代，单个应用被拆分为多个应用，每个应用集群部署进行负载均衡，那么如果某项业务发生系统错误，开发或运维人员还是以过往单体应用方式登录一台一台登录服务器查看日志来定位问题，这种解决线上问题的效率可想而知。集中式日志收集系统的建设就显得极其重要。通过 Logstash 去收集每台服务器日志文件，然后按定义的正则模板过滤后传输到Kafka 或 redis，然后由另一个 Logstash 从 KafKa 或 redis 读取日志存储到 elasticsearch 中创建索引，最后通过Kibana 展示给开发者或运维人员进行分析。这样大大提升了运维线上问题的效率。除此之外，还可以将收集的日志进行大数据分析，得到更有价值的数据给到高层进行决策。
所以一个完整的集中式日志系统，需要包含以下几个主要特点：
- 收集－能够采集多种来源的日志数据
- 传输－能够稳定的把日志数据传输到中央系统
- 存储－如何存储日志数据
- 分析－可以支持 UI 分析
- 警告－能够提供错误报告，监控机制
ELK 提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。
基本概念
Elasticsearch
Elasticsearch 是一个分布式的搜索和分析引擎，可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch 基于 Lucene 开发，现在是使用最广的开源搜索引擎之一。
- node：即一个 Elasticsearch 的运行实例，使用多播或单播方式发现 cluster 并加入
- cluster：包含一个或多个拥有相同集群名称的 node，其中包含一个master node
- index：类比关系型数据库里的DB，是一个逻辑命名空间
- alias：可以给 index 添加零个或多个alias，通过 alias 使用 index 和根据 index name 访问 index 一样，但是，alias 给我们提供了一种切换 index 的能力，比如重建了 index，取名 customer_online_v2，这时，有了 alias，我要访问新 index，只需要把 alias 添加到新 index 即可，并把 alias 从旧的 index 删除。不用修改代码
- type：类比关系数据库里的Table。其中，一个index可以定义多个type，但一般使用习惯仅配一个type
- mapping：类比关系型数据库中的 schema 概念，mapping 定义了 index 中的 type。mapping 可以显示的定义，也可以在 document 被索引时自动生成，如果有新的 field，Elasticsearch 会自动推测出 field 的 type 并加到 mapping 中
- document：类比关系数据库里的一行记录(record)，document 是 Elasticsearch 里的一个 JSON 对象，包括零个或多个field
- field：类比关系数据库里的 field，每个 field 都有自己的字段类型
- shard：是一个 Lucene 实例。Elasticsearch 基于 Lucene，shard 是一个 Lucene 实例，被 Elasticsearch 自动管理。之前提到，index 是一个逻辑命名空间，shard 是具体的物理概念，建索引、查询等都是具体的 shard 在工作。shard 包括 primary shard 和 replica shard，写数据时，先写到 primary shard，然后，同步到 replica shard，查询时，primary 和 replica 充当相同的作用。replica shard 可以有多份，也可以没有，replica shard 的存在有两个作用，一是容灾，如果 primary shard 挂了，数据也不会丢失，集群仍然能正常工作；二是提高性能，因为 replica 和 primary shard 都能处理查询。另外，如上图右侧红框所示，shard 数和 replica 数都可以设置，但是，shard 数只能在建立 index 时设置，后期不能更改，但是，replica 数可以随时更改
Logstash
Logstash 事件处理有三个阶段：inputs → filters → outputs。是一个接收，处理，转发日志的工具。支持系统日志，webserver 日志，错误日志，应用日志，总之包括所有可以抛出来的日志类型。
Input
输入数据到 logstash，一些常用的输入为：
- file：从文件系统的文件中读取，类似于 tial -f 命令
- syslog：在 514 端口上监听系统日志消息，并根据 RFC3164 标准进行解析
- redis：从 redis service 中读取
- beats：从 filebeat 中读取
Filters
数据中间处理，对数据进行操作，一些常用的过滤器为：
- grok：解析任意文本数据，Grok 是 Logstash 最重要的插件。它的主要作用就是将文本格式的字符串，转换成为具体的结构化的数据，配合正则表达式使用。内置120多个解析语法。官方提供的 grok 表达式：https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns， grok 在线调试：https://grokdebug.herokuapp.com/
- mutate：对字段进行转换。例如对字段进行删除、替换、修改、重命名等
- drop：丢弃一部分 events 不进行处理
- clone：拷贝 event，这个过程中也可以添加或移除字段
- geoip：添加地理信息(为前台 kibana 图形化展示使用)
Outputs
outputs 是 logstash 处理管道的最末端组件。一个 event 可以在处理过程中经过多重输出，但是一旦所有的 outputs 都执行结束，这个 event 也就完成生命周期。一些常见的 outputs 为：
- elasticsearch：可以高效的保存数据，并且能够方便和简单的进行查询
- file：将 event 数据保存到文件中
- graphite：将 event 数据发送到图形化组件中，一个很流行的开源存储图形化展示的组件
Codecs
codecs 是基于数据流的过滤器，它可以作为 input，output 的一部分配置。Codecs 可以帮助你轻松的分割发送过来已经被序列化的数据。一些常见的codecs：
- json：使用 json 格式对数据进行编码/解码
- multiline：将汇多个事件中数据汇总为一个单一的行。比如：java异常信息和堆栈信息
Kibana
Kibana 是一个开源的分析与可视化平台，设计出来用于和 Elasticsearch 一起使用的。可以用 kibana 搜索、查看、交互存放在 Elasticsearch 索引里的数据，使用各种不同的图表、表格、地图等 kibana 能够很轻易地展示高级数据分析与可视化。
ELK架构
下面我们简单画一下利用 ELK 技术栈搭建日志管理平台的最佳架构。
第一种 ELK 架构，是最简单的一种 ELK 架构方式。优点是搭建简单，易于上手。缺点是 Logstash 消耗资源较大，运行占用 CPU 和内存高。另外没有消息队列缓存，存在数据丢失隐患。建议供学习者和小规模集群使用。此架构首先由 Logstash 分布于各个节点上搜集相关日志、数据，并经过分析、过滤后发送给远端服务器上的 Elasticsearch 进行存储，过滤环节是很耗时间和资源的。Elasticsearch 将数据以分片的形式压缩存储并提供多种 API 供用户查询，操作。用户亦可以更直观的通过配置 Kibana Web Portal 方便的对日志查询，并根据数据生成报表。架构图如下：
第二种 ELK 架构，引入了消息队列机制，位于数据源的 Logstash 采集器收集到数据后作为生产者直接将数据/日志传递给 Kafka（或者Redis），注意这里省略了过滤动作，这样对数据源服务器影响最小，因为 Kafka 大家都清楚，它的读写性能是非常高的。另一方面，我们需要独立部署一个专门消费的 Logstash，这个 Logstash 负责过滤，并将过滤好的数据传递给 Elasticsearch 存储。最后由 Kibana 将日志和数据呈现给用户。因为引入了 Kafka（或者Redis）,所以即使远端 Logstash 采集器因故障停止运行，数据将会先被存储下来，从而避免数据丢失。这种架构适合于较大集群的解决方案，但由于 Logstash 中心节点和 Elasticsearch 的负荷会比较重，可将他们配置为集群模式，以分担负荷，这种架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在 Logstash 占用系统资源过多的问题。架构图如下：
官方文档
Elasticsearch
https://www.elastic.co/cn/products/elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/index.html
Elasticsearch中文社区
Logstash
https://www.elastic.co/cn/products/logstash
https://www.elastic.co/guide/en/logstash/6.2/index.html
Kibana
https://www.elastic.co/cn/products/kibana
https://www.elastic.co/guide/en/kibana/6.2/index.html
献上膝盖(☆ω☆)
真的是 强，大佬