关于ELK Stack日志分析系统技术方案探讨

前言

收集日志的方式很多，本片主要讲述ELK方案，其他方案如
采用Apache的成熟组件Flume和Kafka来实现这一套日志采集系统，并使用HDFS来做数据存储。
参考链接：https://blog.csdn.net/dada_1036/article/details/50814889

为什么使用ELK

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

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

基于市场流行度、海量数据的处理功能丰富度、开源等特性，我们选择了使用elk Stack这套技术栈

ELK Stack 简介

ELK 不是一款软件，而是 Elasticsearch、Logstash 和 Kibana 三种软件产品的首字母缩写。这三者都是开源软件，通常配合使用，而且又先后归于 Elastic.co 公司名下，所以被简称为 ELK Stack。根据 Google Trend 的信息显示，ELK Stack 已经成为目前最流行的集中式日志解决方案。

Elasticsearch：分布式搜索和分析引擎，具有高可伸缩、高可靠和易管理等特点。基于 Apache Lucene 构建，能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎，使其具有复杂的搜索功能；
Logstash：数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置；
Kibana：数据分析和可视化平台。通常与 Elasticsearch 配合使用，对其中数据进行搜索、分析和以统计图表的方式展示；
Filebeat：ELK 协议栈的新成员，一个轻量级开源日志文件数据搜集器，基于 Logstash-Forwarder源代码开发，是对它的替代。在需要采集日志数据的server上安装 Filebeat，并指定日志目录或日志文件后，Filebeat就能读取数据，迅速发送到 Logstash 进行解析，亦或直接发送到 Elasticsearch 进行集中式存储和分析。
更多ELK Stack介绍看集中式日志系统 ELK 协议栈详解

---

ELK 常用架构及使用场景介绍

1、 logstash -> elasticsearch -> kibana
2、 filebeats -> elasticsearch -> kibana
3、 logstash -> 消息队列(kafka/redis) -> logstash -> elasticsearch -> kibana
4、 filebeats -> logstash -> elasticsearch -> kibana
5、 filebeats -> 消息队列(kafka/redis) -> logstash -> elasticsearch -> kibana

选型对比

属性\类型	1	2	3	4	5
过滤方式	logstash	elasticsearch Ingest	logstash	logstash	logstash
过滤能力	强	一般	强	强	强
采集速度	一般	快	一般	快	快
采集后传输速度	一般	快	很快	一般	很快
日志规模	较小	大	海量	大	海量
框架重量级	filebeat轻量级	logstash较重	logstash较重	filebeat轻量级	filebeat轻量级
采集源机器cpu、内存消耗	大	小	大	小	小
处理机器cpu、内存消耗	大	大	大	大	大
安装复杂度	4	4	6	5	6
拓展性	es集群	es集群	消息队列、es、logstash集群	es、logstash集群	消息队列、es、logstash集群
安全性	8	8	6	7	6
稳定性	8	7	7.5	8	7
应急能力	8	8	8	8	8
流行度	1	5	6.5	6.5	8

---

选型一、
这种架构非常简单，使用场景也有限。适合单台测试机器查看和分析日志使用。

这种架构的扩展，把一个 Logstash 数据搜集节点扩展到多个，分布于多台机器，将解析好的数据发送到 Elasticsearch server 进行存储，最后在 Kibana 查询、生成日志报表等。详见图 2

这种结构因为需要在各个服务器上部署 Logstash，而它比较消耗 CPU 和内存资源，所以比较适合计算资源丰富的服务器，否则容易造成服务器性能下降，甚至可能导致无法正常工作。

---

选型二、
这种架构引入 Beats 作为日志搜集器。
Beats 将搜集到的数据发送到 Logstash，经 Logstash 解析、过滤后，将其发送到 Elasticsearch 存储，并由 Kibana 呈现给用户。详见图 3。

这种架构解决了 Logstash 在各服务器节点上占用系统资源高的问题。相比 Logstash，Beats 所占系统的 CPU 和内存几乎可以忽略不计。另外，Beats 和 Logstash 之间支持 SSL/TLS 加密传输，客户端和服务器双向认证，保证了通信安全。

因此这种架构适合对数据安全性要求较高，同时各服务器性能比较敏感的场景。

---

选型三、
这种架构适合于日志规模比较庞大的情况。但由于 Logstash 日志解析节点和 Elasticsearch 的负荷比较重，可将他们配置为集群模式，以分担负荷。引入消息队列，均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，但依然存在 Logstash 占用系统资源过多的问题。

---

选型四、
基于 Filebeat 的 ELK 集群架构

选型四解决了logstash资源占用过多的问题，日志庞大的情况下主要压力在于logstash，较多的日志文件网络传输也可能导致日志服务器的文件系统填满，可以引入消息队列。见选型五。

---

选型五、
因为免费的 ELK 没有任何安全机制，所以这里使用了 Nginx 作反向代理，避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证，一定程度上提高安全性。另外，Nginx 本身具有负载均衡的作用，能够提高系统访问性能。

---

---

当前选型

以上五种选型中其实主要区别在于：logstash和filebeat的选用，是否引入消息队列，以及是否引入es和logstash集群
综合主要考虑有以下：

• 相比 logstash，fileBeat做采集功能更加轻量化，相比 Logstash，Beats 所占系统的 CPU 和内存几乎可以忽略不计。根据相关测试数据，8线程8GB内存下，logstash常驻内存660M（JAVA），filebeat常驻内存不到30M（GO）。

• 官方推荐使用filebeat替代logstash做采集功能。

• filebeat 也会和 logstash 一样记住上次读取的偏移。

• 5.x 开始，Elasticsearch 具有解析的能力（像 Logstash 过滤器）— Ingest。这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch。

• filebeat的日志解析功能仍然不够强大，还需要logstash做采集后的日志处理

• 随着日志量的增大，文件存储和传输对于服务器内存和带宽影响大，则需要把数据先推到消息队列，减少采集端服务器文件存储和内存压力，同时引入集群部署，

• 行业流行度看，filebeat支持消息队列之后，更多的公司使用filebeat结合消息队列的集群方式实现。

• 对于安全性和角色的控制，需要使用nginx反向代理实现角色和权限控制

综合以上比对和分析

• 测试系统采用了选型一和选型二：因为单台机器日志收集和应用部署都在同一台机，对于测试系统本机使用了logstash，对于推送到网络组elk集群的日志，使用了filebeat。
• 网络组elk集群，将使用方案四或五：应用服务器部署filebeat，推送至集群的logstash机器，目前数据量小，是否引入消息队列取决于网络组的考虑，对于集群中使用logstash，因为elasticsearch的日志过滤功能较单一，且同样存在性能开销，所以仍需要logstash做数据处理才能满足日志过滤。
• 对于生产系统，则建议采用方案五

---

版本选择

各个版本及更新时间：
https://www.elastic.co/cn/downloads/past-releases#elasticsearch
es 5到7的版本变动，最大是type的变动

• 5.x 支持多种type
• 6.x 只能有一种type
• 7.x 将去除type 没有类型的概念了

考虑使用比较稳定的5./6.，或者7.*
目前测试系统使用了5.6.12和最新版7.4.2，运行中使用7.。
网络组es集群当前使用7.。

elasticsearch和jdk版本
版本向下兼容，但是对不上的话会有很多异常警告，有些功能运用过程中会失败，需要配置文件中配置好对应的版本

参考文档

https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://www.ibm.com/developerworks/cn/opensource/os-cn-elk-filebeat/
https://blog.upx8.com/2320
http://www.51niux.com/?id=203
https://www.elastic.co/cn/blog/elasticsearch-7-4-0-released
https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://www.elastic.co/cn/downloads/past-releases#elasticsearch
https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://blog.csdn.net/u010871982/article/details/79035317/
https://blog.csdn.net/cgs666/article/details/84206025
https://www.cnblogs.com/jingmoxukong/p/8185321.htm