ELK Stack日志分析系统技术方案
前言
收集日志的方式很多，本片主要讲述ELK方案，其他方案如
采用Apache的成熟组件Flume和Kafka来实现这一套日志采集系统，并使用HDFS来做数据存储。
参考链接：https://blog.****.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.****.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.****.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://www.elastic.co/cn/downloads/past-releases#elasticsearch
https://www.****.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://blog.****.net/u010871982/article/details/79035317/
https://blog.****.net/cgs666/article/details/84206025
https://www.cnblogs.com/jingmoxukong/p/8185321.htm