详解日志采集工具--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 之间的关系相似。

典型应用场景

Fluentd 在日志的数据源和目标存储各类各样时很是合适，由于它有不少插件。并且，若是大多数数据源都是自定义的应用，因此能够发现用 fluentd 的库要比将日志库与其余传输工具结合起来要容易不少。特别是在咱们的应用是多种语言编写的时候，即咱们使用了多种日志库，日志的行为也不太同样。

Logagent

Logagent 是 Sematext 提供的传输工具，它用来将日志传输到 Logsene(一个基于 SaaS 平台的 Elasticsearch API)，由于 Logsene 会暴露 Elasticsearch API，因此 Logagent 能够很容易将数据推送到 Elasticsearch 。

优点

能够获取 /var/log 下的全部信息，解析各类格式(Elasticsearch，Solr，MongoDB，Apache HTTPD等等)，它能够掩盖敏感的数据信息，例如，我的验证信息(PII)，出生年月日，信用卡号码，等等。它还能够基于 IP 作 GeoIP 丰富地理位置信息(例如，access logs)。一样，它轻量又快速，能够将其置入任何日志块中。在新的 2.0 版本中，它以第三方 node.js 模块化方式增长了支持对输入输出的处理插件。重要的是 Logagent 有本地缓冲，因此不像 Logstash ，在数据传输目的地不可用时会丢失日志。

劣势

尽管 Logagent 有些比较有意思的功能(例如，接收 Heroku 或 CloudFoundry 日志)，可是它并无 Logstash 灵活。

典型应用场景

Logagent 做为一个能够作全部事情的传输工具是值得选择的(提取、解析、缓冲和传输)。

logtail

阿里云日志服务的生产者，目前在阿里集团内部机器上运行，通过3年多时间的考验，目前为阿里公有云用户提供日志收集服务。

采用C++语言实现，对稳定性、资源控制、管理等下过很大的功夫，性能良好。相比于logstash、fluentd的社区支持，logtail功能较为单一，专一日志收集功能。

优点

logtail占用机器cpu、内存资源最少，结合阿里云日志服务的E2E体验良好。

劣势

logtail目前对特定日志类型解析的支持较弱，后续须要把这一块补起来。

rsyslog

绝大多数 Linux 发布版本默认的 syslog 守护进程，rsyslog 能够作的不只仅是将日志从 syslog socket 读取并写入 /var/log/messages 。它能够提取文件、解析、缓冲(磁盘和内存)以及将它们传输到多个目的地，包括 Elasticsearch 。能够今后处找到如何处理 Apache 以及系统日志。

优点

rsyslog 是经测试过的最快的传输工具。若是只是将它做为一个简单的 router/shipper 使用，几乎全部的机器都会受带宽的限制，可是它很是擅长处理解析多个规则。它基于语法的模块(mmnormalize)不管规则数目如何增长，它的处理速度始终是线性增加的。这也就意味着，若是当规则在 20-30 条时，如解析 Cisco 日志时，它的性能能够大大超过基于正则式解析的 grok ，达到 100 倍(固然，这也取决于 grok 的实现以及 liblognorm 的版本)。

它同时也是咱们能找到的最轻的解析器，固然这也取决于咱们配置的缓冲。

劣势

rsyslog 的配置工做须要更大的代价(这里有一些例子)，这让两件事情很是困难：

文档难以搜索和阅读，特别是那些对术语比较陌生的开发者。

5.x 以上的版本格式不太同样(它扩展了 syslogd 的配置格式，同时也仍然支持旧的格式)，尽管新的格式能够兼容旧格式，可是新的特性(例如，Elasticsearch 的输出)只在新的配置下才有效，而后旧的插件(例如，Postgres 输出)只在旧格式下支持。

尽管在配置稳定的状况下，rsyslog 是可靠的(它自身也提供多种配置方式，最终均可以得到相同的结果)，它仍是存在一些 bug 。

典型应用场景

rsyslog 适合那些很是轻的应用(应用，小VM，Docker容器)。若是须要在另外一个传输工具(例如，Logstash)中进行处理，能够直接经过 TCP 转发 JSON ，或者链接 Kafka/Redis 缓冲。

rsyslog 还适合咱们对性能有着很是严格的要求时，特别是在有多个解析规则时。那么这就值得为之投入更多的时间研究它的配置。

以为不错请点赞支持，欢迎留言或进个人我的群855801563领取【架构资料专题目合集90期】、【BATJTMD大厂JAVA面试真题1000+】，本群专用于学习交流技术、分享面试机会，拒绝广告，我也会在群内不按期答题、探讨。