1、ELK介绍

ELK 是elastic公司提供的一套完整的日志收集以及展示的解决方案，是三个产品的首字母缩写，分别是ElasticSearch、Logstash 和 Kibana。

ElasticSearch简称ES，是一个基于Lucene的、支持全文索引的分布式存储和索引引擎，主要负责将日志索引存储起来，方便业务搜索查询，使用 Java 语言编写。
Logstash是一个具有实时传输能力的数据收集引擎，是日志收集、过滤、转发的中间件，主要负责将各条业务线的各类日志统一收集、过滤后，转发给Elasticsearch进行下一步处理。
Kibana为 Elasticsearch 提供了分析和可视化的 Web 平台。它可以在 Elasticsearch 的索引中查找，交互数据，并生成各种维度表格、图形。

2、ELK解决问题、实现功能

问题	效果
(1)开发人员不能完全登录线上服务器查看详细日志。	(1)日志平台化，查询方便。
(2)各个系统都有日志、日志数据分散难以查找。	(2)日志集中，且经过过滤梳理。
(3)日志数据量大，查询速度慢，或者数据不够实时。	(3)通过底层插件实现数据的快速采集与存储

3、ELK的用途

传统意义上，ELK是作为替代Splunk的一个开源解决方案。Splunk 是日志分析领域的领导者。日志分析并不仅仅包括系统产生的错误日志，异常，也包括业务逻辑，或者任何文本类的分析。而基于日志的分析，能够在其上产生非常多的解决方案，譬如：

1.问题排查。我们常说，运维和开发这一辈子无非就是和问题在战斗，所以这个说起来很朴实的四个字，其实是沉甸甸的。很多公司其实不缺钱，就要稳定，而要稳定，就要运维和开发能够快速的定位问题，甚至防微杜渐，把问题杀死在摇篮里。日志分析技术显然问题排查的基石。基于日志做问题排查，还有一个很帅的技术，叫全链路追踪，比如阿里的eagleeye 或者Google的dapper，也算是日志分析技术里的一种。
2.监控和预警。 日志，监控，预警是相辅相成的。基于日志的监控，预警使得运维有自己的机械战队，大大节省人力以及延长运维的寿命。
3.关联事件。多个数据源产生的日志进行联动分析，通过某种分析算法，就能够解决生活中各个问题。比如金融里的风险欺诈等。这个可以可以应用到无数领域了，取决于你的想象力。
4.数据分析。 这个对于数据分析师，还有算法工程师都是有所裨益的。

4、ELK火热的原因？

4.1、与传统日志处理方案相比，Elasticsearch的优点：

1.处理方式灵活。Elasticsearch是实时全文索引，不需要像storm那样先编程才能使用；
2.配置简单上手。Elasticsearch全部采用JSON接口，Logstash是Ruby DSL设计，都是目前业界最通用的配置语法设计；
3.检索性能高效。虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应；
4.集群线性扩展。不管是Elasticsearch集群还是Logstash集群都是可以线性扩展的；
5.前端操作炫丽。kibana；

4.2、ELK之前，有没有类似解决方案呢？

某大神说是有的，当时应该是基于 Sphinx + Google char的。 Sphinx 对应ES, Google char 对应 Kibana。

那为啥当时它没有火而现在的ELK火了呢？一种比较玄幻的解释是：
事实上开源界永远有多种选择，比如基于java的lucene的es，也有基于c的lucy的dezi。但是谁火谁不火，真的是一个很玄妙的事情。
我觉得原因有很多方面，一个简单而较为核心的因数是时机，所谓时势造英雄是也。当然，任何一件事情不可能是一个因子引起的，或者我们说时机是一个较为宽泛抽象的因子。

4.3、下面我从多个因素去阐述为什么ELK突然蓬勃发展？

1.数据(日志)的日益增多：
早年能够产生足够数据的就那么一些站点，而现在一个初创的企业可能都需要面临海量用户/海量请求/海量分析的压力，其中产生的日志自然也是非常可观，而随着业务越来越复杂，微服务重新得到重视，无论系统日志，还是业务日志都更进一步了。运维或者开发们发现，我要从这么大规模的系统中(几百个上千个服务)产生的这么多日志(千亿规模)，去排查问题，简直是没有可能了。以前有这么大数据量的公司，都是有实力的公司，他们可能有内部专用的系统去处理。然而现在突然成为了一个普遍需求，这个时候ELK顺势而上，也就水到渠成。

2.开源：
开源现在已经融入到IT社区的血液里。虽然我们说商业,自研，还有开源三者之间是相辅相成，相濡以沫或者偶尔会相爱相杀，但是如果有开源可以选择，显然大部分开发或者运维还是首选开源的。有位大牛说的好：
ELK其开源属性，显然是比Splunk 略胜一筹的。

3.行业属性：
有些行业对日志的依赖是非常大的，比如 CDN 日志除了能排查错误，对其分析还能对CDN调度等很多方面产生影响，这些都是实打实的经济效益。

4.运维自身发展：
运维本身也在发展，不可能一直在刀耕火种的年代。而日志对于运维来说，应该算是命根子了。对一个成体系的，标准化的日志分析方案的需求，也是历史发展的必然。ELK在恰当的时候产生，运维接受他就是自然而然的了。

5.ELK自身属性问题：
引用一位大神的说法：
ELK能解决的核心问题，覆盖面也广，标准化，易扩展集成，开发和运维都对其感冒，ELK 本身非常易用，现在也有一个非常好的社区，加上需求如此之大，不火都不行。

6.大数据导致机器开始变得廉价：
大数据的一个很好的副作用是让机器在某种意义上变得廉价了。少则几十上百台，多则上万甚至几十万台。服务器数量的急速攀升促进了很多技术的发展，典型的比如现在火的不要不要的深度学习。这就意味着，拿出几十台，上百台服务器做日志分析，一点问题也没有，集中式的日志分析慢慢成为主流。而ELK也是一个典型的集中式日志分析方案。

7.写入时计算->查询时计算：
所谓写入时计算是指将数据经过较为复杂的处理，聚合，得到的结果直接面向查询。 写入时计算规则由查询需求决定。随着存储格式的不断进步，譬如列式存储等的普及，以及强大的计算资源(一个ES集群动则上百台)，使得直接存储原汁原味的数据，然后查询的时候做各种计算变得可能。而ELK已经提供较为强大的查询功能。总体而言，写入时计算的大方向是往查询时计算转化。查询时计算最大的优势是支持任意查询，不丢失信息。

5、ELK组成

5.1、elasticsearch

1.elasticsearch几个重要术语
elasticsearch是一个近似实时的搜索平台，从索引文档到可搜索有些延迟，通常为1秒。

分片（shards）和副本（replicas）：
在实际情况下，索引存储的数据可能超过单个节点的硬件限制。如一个十亿文档需 1TB 空间可能不适合存储 在单个节点的磁盘上，或者从单个节点搜索请求太慢了。为了解决这个问题， elasticsearch 提供将索引分成多个分片的功能。当在创建索引时，可以定义想要分片的数量。每一个分片就是一个全功能的独立的索 引，可以位于集群中任何节点上。

分片的两个最主要原因：
a、水平分割扩展，增大存储量；
b、分布式并行跨分片操作，提高性能和吞吐量。分布式分片的机制和搜索请求的文档如何汇总完全是有 elasticsearch 控制的，这些对用户 而言是透明 的。 网络问题等等其它问题可以在任何时候不期而至，为了健壮性，强烈建议要有一个故障切换机制，无论 何种故障以防止分片或者节点不可用。 为此，elasticsearch 让我们将索引分片复制一份或多份，称之为分片副本或副本。

副本也有两个最主要原因：
a、高可用性，以应对分片或者节点故障。出于这个原因，分片副本要在不同的节点上；
b、提高性能，增大吞吐量，搜索可以并行在所有副本上执行，总之，每一个索引可以被分成多个分片。索引 也可以有0个或多个副本。复制后，每个索引都有主分片(母分片)和复制分片(复制于母分片)。分片和副本数量可以在每个索引被创建时定义。索引创建后，可以在任何时候动态的更改副本数量，但是，不能改变分片数。默认情况下，elasticsearch为每个索引分片5个主分片和1个副本，这就意味着集群至少需要2个节点。索引将会有5个主分片和5个副本(1个完整副本)，每个索引总共有10个分片。

5.2、logstash

1.logstash介绍
LogStash 由 JRuby 语言编写，基于消息（message-based）的简单架构，并运行在Java虚拟机(JVM)上。不同于分离的代理端(agent)或主机端(server)，LogStash可配置单一的代理端(agent)与其它开源软件结合，以实现不同的功能。Logstash 是一个完全开源的工具，他可以对你的日志进行收集、分析，并将其存储供以后使用。

2.logstash的四大组件

3.logstash主机分类
代理主机（agent host）：作为事件的传递者（shipper），将各种日志数据发送至中心主机；只需运行 Logstash 代理（agent）程序；
中心主机（central host）：可运行包括中间转发器（Broker）、索引器（Indexer）、搜索和存储器 （Search and Storage）、Web 界面端（Web Interface）在内的各个组件，以 实现对日志数据的接 收、处理和存储。

5.3、kibana

Kibana是一个开源的分析与可视化平台，设计出来用于和Elasticsearch一起使用的。你可以用kibana搜索、查看、交互存放在Elasticsearch索引里的数据，使用各种不同的图表、表格、地图等kibana能够很轻易地展示高级数据分析与可视化。

6、ELK架构

6.1、Logstash+Elasticsearch+Kibana

首先由Logstash分布于各个节点上搜索相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩后存储并提供多种API供用户查询、操作。用户也可以更直观的通过配置Kibana WebPortal方便对日志查询，并根据数据生成报表。

优点： 搭建简单，易上手。
缺点： Logstash消耗资源大，运行占用cpu和内存高，另外没有消息队列缓存，存在数据丢失隐患。
应用场景： 适合小规模集群使用。

6.2、Logstash+Kafka+Elasticsearch+Kibana

第二种架构引入消息队列机制，位于各个节点上的Logstash Agent先将数据/日志传递给Kafka（或者redis），并将队列中消息或数据间接传递给Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入Kafka（或者redis），所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。
优点： 引入消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性。
缺点： 依然存在Logstash占用系统资源过多的问题。
应用场景： 适合较大集群方案。

6.3、FileBeat+Logstash+Elasticsearch+Kibana

此架构将收集端Logstash替换为FlieBeat，更灵活，消耗资源更少，扩展性更强。同时可配置Logstash和Kibana集群用于支持大集群的运维日志数据监控和查询。

不管采用上面哪种ELK架构，都包含了其核心组件，即：Logstash、Elasticsearch和Kibana。当然这三个组件并非不能被替换，只是就性能和功能而言，这三个组件已经配合的很完美，是密不可分的。在运维中终究改采用哪种架构，可根据实际情况和架构优劣而定。

参考文章：https://blog.****.net/qiushisoftware/article/details/100298046