ELK-B简述和架构分析

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的）