ELK-B简述和架构分析

一、ELK简介

ELK分别表示Elasticsearch、Logstash、Kibana，是一套完整的日志收集以及展示的解决方案。新增了一个FileBeat，是一个轻量型的日志收集处理工具，FileBeat占用的资源少，适合在各个服务器上搜集日志后传输给Logstash；

 

二、ELK-B介绍

• Elasticsearch简称ES，是一个基于Lucene的、支持全文索引的分布式存储和索引引擎，提供搜集、分析、存储数据三大功能，特点是具备分布式、零配置、自动发现、索引自动分片、索引副本机制、restFul风格接口、多数据源、自动搜索负载等。主要负责将日志索引存储起来，方便业务搜索查询；
• Logstash是一个具有实时传输能力的数据收集引擎，是日志收集、过滤、转发的中间件，支持大量的数据获取方式，一般工作方式为C/S架构，client端安装在需要收集日志的主机上，Server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去，主要负责将各条业务线的各类日志统一收集、过滤后、转发给ES进行下一步的处理；
• Kibana提供给了ES和Logstash一个友好的可视化Web界面，可以帮助汇总、分析和搜索重要数据汇总，可以在ES的索引中查找，交互数据，并且生成各种纬度表格；
• FileBeat，是一个轻量级的开源日志文件数据搜集器，基于Logstash-Forwarder源代码开发，在需要采集的Server上安装FileBeat，并且指定日志目录或者日志文件后，FileBeat就能读取数据，迅速发送到Logstash进行解析，也可以直接发送到ES中进行集中式的存储和分析；

Beats作为日志收集器，使用beats的日志收集器架构，目前beats包括四种：

• Packetbeat（搜集网络流量数据）
• Filebeat（搜集文件数据）
• Topbeat（搜集系统、进程、文件系统级别的CPU和内存使用情况等数据）
• Winlogbeat（搜集Windows事件的日志数据）

 

三、ELK解决的问题、功能、用途

A、解决的问题和实现的功能效果

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

 

B、ELK的用途

ELK是一个日志收集分析系统，日志分析并不是仅仅包括系统产生的错误日志，异常，也包括业务逻辑，或者任何文本类的分析。而基于日志的分析，能够在其上产生很多解决方案；

1. 问题排查：日志分析技术显然问题排查的基石。基于日志做问题排查也叫全链追踪；
2. 监控与预警：日志，监控，预警是相辅相成的。基于日志的监控，预警使得运维有自己的机械战队，大大节省人力以及延长运维的寿命。
3. 关联事件：多个数据源产生的日志进行联动分析，通过某种分析算法，就能够解决生活中各个问题。比如金融里的风险欺诈等。
4. 数据分析；

四、与传统日志处理方案相比，ELK存在的优点

优点

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

其他的解决方案

参考：基于 Sphinx + Google char的。 Sphinx 对应ES, Google char 对应 Kibana。

五、ELK架构方式

5.1、Logstash+ES+Kibana

由Logstash分布于各个节点上搜索相关日志、数据，并经过分析、过滤后发送给远端服务器上的Elasticsearch进行存储。Elasticsearch将数据以分片的形式压缩后存储并提供多种API供用户查询、操作。用户也可以更直观的通过配置Kibana WebPortal方便对日志查询，并根据数据生成报表。
优点： 搭建简单，易上手。
缺点： Logstash消耗资源大，运行占用cpu和内存高，另外没有消息队列缓存，存在数据丢失隐患。
应用场景： 适合小规模集群使用。

---

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

5.2、Logstash+Kafka+ES+Kibana

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

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

Beats还不支持输出到消息队列，所以消息队列前后两端只能是Logstash实例，这种架构使用logstash从各个数据源搜集数据，然后经过消息队列输出到消息队列中，目前Logstash支持Kafka、Redis、RabbitMQ等常见的消息队列，然后Logstash通过消息队列输入插件从队列中获取数据，分析过滤后输出插件发送到ES中，最后通过Kibana展示；

5.3、FileBeat+LogStash+ES+Kibana

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

基于FileBeat的ELK集群架构；

---

上面架构都包含了ELK，这三种组件不能被替换；

ELK安装与教程（更多的是ES的）