ELK学习总结（1）——我们为什么要用ELK

爱被打了一巴掌 2021-10-20 01:18 344阅读 0赞

# **一. ELK是什么？** #

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70][]

*  **ElasticSearch简称ES**，它是一个实时的分布式搜索和分析引擎，它可以用于全文搜索，结构化搜索以及分析。它是一个建立在全文搜索引擎 Apache Lucene 基础上的搜索引擎，使用 Java 语言编写。
 *  **Logstash**是一个具有实时传输能力的数据收集引擎，用来进行数据收集（如：读取文本文件）、解析，并将数据发送给ES。
 *  **Kibana**为 Elasticsearch 提供了分析和可视化的 Web 平台。它可以在 Elasticsearch 的索引中查找，交互数据，并生成各种维度表格、图形。

# **二：ELK的用途** #

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1][]

# **三：ELK火热的原因？** #

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

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

**那为啥当时它没有火而现在的ELK火了呢？一种比较玄幻的解释是**：

> 事实上开源界永远有多种选择，比如基于java的lucene的es，也有基于c的lucy的dezi。但是谁火谁不火，真的是一个很玄妙的事情

我觉得原因有很多方面，一个简单而较为核心的因数是时机，所谓时势造英雄是也。当然，任何一件事情不可能是一个因子引起的，或者我们说时机是一个较为宽泛抽象的因子。

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

**1，数据(日志)的日益增多：**

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

**2，开源：**

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

> 开源及其便利性，开源的好处，学习成本底，招一个人就能培养他开干，一个内部维护的系统，新人上火总会问题很多；比如要重构还不如重写，或者不愿在人家的代码基础上开发

**ELK其开源属性，显然是比Splunk 略胜一筹的。**

**3，行业属性：**

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

**4，运维自身发展：**

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

**5，ELK自身属性问题：**

引用一位大神的说法：

> ELK能解决的核心问题，覆盖面也广，标准化，易扩展集成，开发和运维都对其感冒

**ELK 本身非常易用，现在也有一个非常好的社区，加上需求如此之大，不火都不行。**

**6，大数据导致机器开始变得廉价：**

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

**7，写入时计算->查询时计算：**

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]: /images/20211019/96f27cba3e034316a5daee1fafbc7e73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ2hhaXlhbmcuYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]: /images/20211019/add9a2550b4443ad9c0c2f64409ac813.png