详解日志采集工具--Logstash、Filebeat、Fluentd、Logagent对比

 概述

常见的日记收罗器材有Logstash、Filebeat、Fluentd、Logagent、rsyslog等等，那么他们之间有什么区别呢?什么环境下我们应该用哪一种器材?

Logstash

Logstash是一个开源数据网络引擎，具有及时管道成果。Logstash可以动态地未来自差异数据源的数据同一路来，并将数据尺度化到你所选择的目标地。

上风

Logstash 首要的有点就是它的机动性，首要由于它有许多插件，具体的文档以及直白的设置名目让它可以在多种场景下应用。我们根基上可以在网上找到许多资源，险些可以处理赏罚任何题目。

劣势

Logstash 致命的题目是它的机能以及资源耗损(默认的堆巨细是 1GB)。尽量它的机能在近几年已经有很大晋升，与它的更换者们对比照旧要慢许多的。这里有 Logstash 与 rsyslog 机能比拟以及Logstash 与 filebeat 的机能比拟。它在大数据量的环境下会是个题目。

另一个题目是它今朝不支持缓存，今朝的典范更换方案是将 Redis 或 Kafka 作为中心缓冲池：

典范应用场景

由于 Logstash 自身的机动性以及收集上富厚的资料，Logstash 合用于原型验证阶段行使，可能理会很是的伟大的时辰。在不思量处事器资源的环境下，假如处事器的机能足够好，我们也可觉得每台处事器安装 Logstash 。我们也不必要行使缓冲，由于文件自身就有缓冲的举动，而 Logstash 也会记着前次处理赏罚的位置。

假如处事器机能较差，并不保举为每个处事器安装 Logstash ，这样就必要一个轻量的日记传输器材，将数据从处事器端经过一个或多个 Logstash 中心处事器传输到 Elasticsearch：

跟着日记项目标推进，也许会由于机能或价钱的题目，必要调解日记传输的方法(log shipper)。当判定 Logstash 的机能是否足够好时，重要的是对吞吐量的需求有着精确的预计，这也抉择了必要为 Logstash 投入几多硬件资源。

Filebeat

作为 Beats 家属的一员，Filebeat 是一个轻量级的日记传输器材，它的存在正补充了 Logstash 的弱点：Filebeat 作为一个轻量级的日记传输器材可以将日记推送到中心 Logstash。

在版本 5.x 中，Elasticsearch 具有理会的手段(像 Logstash 过滤器)— Ingest。这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch，并让 Elasticsearch 既做理会的工作，又做存储的工作。也不必要行使缓冲，由于 Filebeat 也会和 Logstash 一样记着前次读取的偏移，假如必要缓冲(譬喻，不但愿将日记处事器的文件体系填满)，可以行使 Redis/Kafka，由于 Filebeat 可以与它们举办通讯。

上风

Filebeat 只是一个二进制文件没有任何依靠。它占用资源少少，尽量它还异常年青，正式由于它简朴，以是险些没有什么可以堕落的处所，以是它的靠得住性照旧很高的。它也为我们提供了许多可以调理的点，譬喻：它以何种方法搜刮新的文件，以及当文件有一段时刻没有产生变革时，何时选择封锁文件句柄。

劣势

Filebeat 的应用范畴异常有限，以是在某些场景下我们会遇到题目。譬喻，假如行使 Logstash 作为下流管道，我们同样会碰着机能题目。正由于云云，Filebeat 的范畴在扩大。开始时，它只能将日记发送到 Logstash 和 Elasticsearch，而此刻它可以将日记发送给 Kafka 和 Redis，在 5.x 版本中，它还具备过滤的手段。

典范应用场景

Filebeat 在办理某些特定的题目时：日记存于文件，我们但愿将日记直接传输存储到 Elasticsearch。这仅在我们只是抓去(grep)它们可能日记是存于 JSON 名目(Filebeat 可以理会 JSON)。可能假如规划行使 Elasticsearch 的 Ingest 成果对日记举办理会和富厚。

将日记发送到 Kafka/Redis。以是其它一个传输器材(譬喻，Logstash 或自界说的 Kafka 斲丧者)可以进一步富厚和转发。这里假设选择的下流传输器材可以或许满意我们对成果和机能的要求。

Fluentd

Fluentd 建设的初志首要是尽也许的行使 JSON 作为日记输出，以是传输器材及其下流的传输线不必要揣摩子字符串内里各个字段的范例。这样，它为险些全部的说话都提供库，这也意味着，我们可以将它插入到我们自界说的措施中。

上风

和大都 Logstash 插件一样，Fluentd 插件是用 Ruby 说话开拓的很是易于编写维护。以是它数目许多，险些全部的源和方针存储都有插件(各个插件的成熟度也不太一样)。这也意味这我们可以用 Fluentd 来串联全部的对象。

劣势

由于在大都应用场景下，我们会通过 Fluentd 获得布局化的数据，它的机动性并欠好。可是我们如故可以通过正则表达式，来理会非布局化的数据。尽量，机能在大大都场景下都很好，但它并不是最好的，和 syslog-ng 一样，它的缓冲只存在与输出端，单线程焦点以及 Ruby GIL 实现的插件意味着它大的节点下机能是受限的，不外，它的资源耗损在大大都场景下是可以接管的。对付小的可能嵌入式的装备，也许必要看看 Fluent Bit，它和 Fluentd 的相关与 Filebeat 和 Logstash 之间的相关相同。

典范应用场景

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!