从ELK 到 EFK （日志分析系统简介）

一、日志系统

1.1为什么需要日志系统

1. 保留现场
2. 自知者自明
3. 所有即将发生的，都取决于已经发生的
4. 数据商业化运作

1.1日志管理系统的解决方案

1. 机器上的日志实时收集，存储到日志中心
2. 给日志建立索引，通过索引能很快找到日志
3. 架设web界面，在web上完成日志的搜索

1.1日志管理系统的困难

1. 日志量很大，每天几十亿条
2. 日志的实时收集，延迟控制在分钟级别
3. 能够在线水平扩展

二、从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 投入多少硬件资源。