从ELK 到 EFK 日志分析系统简介
- 一、日志系统
- 1.1为什么需要日志系统
- 1.1日志管理系统的解决方案
- 1.1日志管理系统的困难
- 二、从ELK到EFK
- 2.1简介
- 2.2 各个软件的介绍
- 2.2.1 ElasticSearch
- 2.2.2 Kibana
- 2.2.3 Filebeat
- 2.2.4 Logstash
一、日志系统
1.1为什么需要日志系统
- 保留现场
- 自知者自明
- 所有即将发生的,都取决于已经发生的
- 数据商业化运作
1.1日志管理系统的解决方案
- 机器上的日志实时收集,存储到日志中心
- 给日志建立索引,通过索引能很快找到日志
- 架设web界面,在web上完成日志的搜索
1.1日志管理系统的困难
- 日志量很大,每天几十亿条
- 日志的实时收集,延迟控制在分钟级别
- 能够在线水平扩展
二、从ELK到EFK
2.1简介
EFK与ELK 不是一个软件,而是一套解决方案。
ELK是Logstash、Elasticsearch、Kibana的集合。其中 ELasticsearch 负责日志分析和存储,Logstash负责日志收集,Kibana 负责界面展示。
EFK 是Elasticsearch,FileBeat,Kibana的集合。与ELK不同的是,FileBeat替代了Logstash,负责日志收集。
ELK和EFK的各个组件,它们之间互相配合使用,完美衔接,高效的满足了很多场合的应用,是目前主流的两种日志分析系统解决方案。
软件名称 | 用途 |
Elasticsearch | 分布式搜索和分析引擎,具有高可伸缩、高可靠和易管理等特点。基于 Apache Lucene 构建,能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎,使其具有复杂的搜索功能 |
Logstash | 数据收集引擎。它支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储到用户指定的位置 |
Filebeat | 轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说:Filebeat就是新版的 Logstash-fowarder,也会是 ELK Stack 在 shipper 端的第一选择 |
Kibana | 数据分析和可视化平台。通常与 Elasticsearch 配合使用,对其中数据进行搜索、分析和以统计图表的方式展示 |
2.2 各个软件的介绍
2.2.1 ElasticSearch
ElasticSearch是一个基 于Lucene的搜索服务器。它提供了-个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是 用Java开发的,并作为Apache许可条款 下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。
2.2.2 Kibana
Kibana 是用于在 Elasticsearch 中可视化数据的强大工具。 是一种开源分析和可视化工具,可通过基于浏览器的界面轻松搜索、查看存储在Elasticsearch索引中的数据,通过各种图表进行高级数据分析及展示。
2.2.3 Filebeat
优势:
Filebeat 只是一个二进制文件没有任何依赖。它占用资源极少,尽管它还十分年轻,正式因为它简单,所以几乎没有什么可以出错的地方,所以它的可靠性还是很高的。它也为我们提供了很多可以调节的点,例如:它以何种方式搜索新的文件,以及当文件有一段时间没有发生变化时,何时选择关闭文件句柄。
劣势:
Filebeat 的应用范围十分有限,所以在某些场景下我们会碰到问题。例如,如果使用 Logstash 作为下游管道,我们同样会遇到性能问题。正因为如此,Filebeat 的范围在扩大。开始时,它只能将日志发送到 Logstash 和 Elasticsearch,而现在它可以将日志发送给 Kafka 和 Redis,在 5.x 版本中,它还具备过滤的能力。
典型应用场景:
Filebeat 在解决某些特定的问题时:日志存于文件,我们希望将日志直接传输存储到 Elasticsearch。这仅在我们只是抓去(grep)它们或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)。或者如果打算使用 Elasticsearch 的 Ingest 功能对日志进行解析和丰富。将日志发送到 Kafka/Redis。所以另外一个传输工具(例如,Logstash 或自定义的 Kafka 消费者)可以进一步丰富和转发。这里假设选择的下游传输工具能够满足我们对功能和性能的要求。
2.2.4 Logstash
优势:
Logstash 主要的有点就是它的灵活性,主要因为它有很多插件,详细的文档以及直白的配置格式让它可以在多种场景下应用。我们基本上可以在网上找到很多资源,几乎可以处理任何问题。
劣势:
Logstash 致命的问题是它的性能以及资源消耗(默认的堆大小是 1GB)。尽管它的性能在近几年已经有很大提升,与它的替代者们相比还是要慢很多的。这里有 Logstash 与 rsyslog 性能对比以及Logstash 与 filebeat 的性能对比。它在大数据量的情况下会是个问题。另一个问题是它目前不支持缓存,目前的典型替代方案是将 Redis 或 Kafka 作为中心缓冲池:
典型应用场景:
因为 Logstash 自身的灵活性以及网络上丰富的资料,Logstash 适用于原型验证阶段使用,或者解析非常的复杂的时候。在不考虑服务器资源的情况下,如果服务器的性能足够好,我们也可以为每台服务器安装 Logstash 。我们也不需要使用缓冲,因为文件自身就有缓冲的行为,而 Logstash 也会记住上次处理的位置。如果服务器性能较差,并不推荐为每个服务器安装 Logstash ,这样就需要一个轻量的日志传输工具,将数据从服务器端经由一个或多个 Logstash 中心服务器传输到 Elasticsearch:随着日志项目的推进,可能会因为性能或代价的问题,需要调整日志传输的方式(log shipper)。当判断 Logstash 的性能是否足够好时,重要的是对吞吐量的需求有着准确的估计,这也决定了需要为 Logstash 投入多少硬件资源。