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-B简述和架构分析_第1张图片

 

三、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和内存高,另外没有消息队列缓存,存在数据丢失隐患。
应用场景: 适合小规模集群使用。

ELK-B简述和架构分析_第2张图片


ELK-B简述和架构分析_第3张图片

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

5.2、Logstash+Kafka+ES+Kibana

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

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

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

5.3、FileBeat+LogStash+ES+Kibana

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

ELK-B简述和架构分析_第5张图片

基于FileBeat的ELK集群架构;


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


ELK安装与教程(更多的是ES的)

 

 

你可能感兴趣的:(elk,架构,java,elasticsearch,搜索引擎)