当谈及集中日志到 Elasticsearch 时，首先想到的日志传输（log shipper）便是 Logstash。开拓者听说过它，但是不太清楚它详细是干什么事情的：
当深入这个话题时，我们才明白集中存储日志常日隐含着很多的事情，Logstash 也不是唯一的日志传输工具（log shipper）
从数据源获取数据：文件、UNIX socket、TCP、UDP 等等处理：添加韶光戳、解析非构造化数据、根据 IP 添加地理位置信息传输：到目标存储。比如，Elasticsearch 。由于 Elasticsearch 可能会宕机，或正存在性能问题，或网络存在问题，那么传输工具最好就须要有能力供应缓冲以及重试。本篇博文旨在比较 Logstash 已经它的五种替代方案（Filebeat、Fluentd、rsyslog、syslog-ng 以及 Logagent），这样就可以知道它们各适宜于何种场景。
剖析
Logstash
Logstash 不是这个列表里最老的传输工具（最老的该当是 syslog-ng ，讽刺的是它也是唯一一个名字里带有 new 的），但 Logstash 绝对可以称得上最有名的。由于它有很多插件：输入、编解码器、过滤器以及输出。基本上，可以获取并丰富任何数据，然后将它们推送到多种目标存储。
上风
Logstash 紧张的有点便是它的灵巧性，这还紧张由于它有很多插件。然后它清楚的文档已经直白的配置格式让它可以再多种场景下运用。这样的良性循环让我们可以在网上找到很多资源，险些可以处理任何问题。以下是一些例子：
5 minute introreindexing data in Elasticsearchparsing Elasticsearch logsrewriting Elasticsearch slowlogs so you can replay them with JMeter劣势
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 消费者）可以进一步丰富和转发。这里假设选择的下贱传输工具能够知足我们对功能和性能的哀求。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 作为一个可以做所有事情的传输工具是值得选择的（提取、解析、缓冲和传输）。
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 还适宜我们对性能有着非常严格的哀求时，特殊是在有多个解析规则时。那么这就值得为之投入更多的韶光研究它的配置。
syslog-ng
可以将 syslog-ng 当作 rsyslog 的替代品（只管历史上它们是两种不同的办法）。它也是一个模块化的 syslog 守护进程，但是它可以做的事情要比 syslog 多。它可以吸收磁盘缓冲并将 Elasticsearch HTTP 作为输出。它利用 PatternDB 作为语法解析的根本，作为 Elasticsearch 的传输工具，它是一个不错的选择。
上风
和 rsyslog 一样，作为一个轻量级的传输工具，它的性能也非常好。它曾经比 rsyslog 慢很多，但是 2 年前能达到 570K Logs/s 的性能并不差。并不像 rsyslog ，它有着明确同等的配置格式以及无缺的文档。
劣势
Linux 发布版本转向利用 rsyslog 的缘故原由是 syslog-ng 高等版曾经有很多功能在开源版中都存在，但是后来又有所限定。我们这里只关注与开源版本，所有的日志传输工具都是开源的。现在又有所变革，例如磁盘缓冲，曾经是高等版存在的特性，现在开源版也有。但有些特性，例如带有运用层的关照的可靠传输协议（reliable delivery protocol）还没有在开源版本中。
范例运用处景
和 rsyslog 类似，可能将 syslog-ng 支配在资源受限的环境中，但仍希望它能在处理繁芜打算时有着良好的性能。如果利用 rsyslog ，它可以输出至 Kafka ，以 Kafka 作为一个中央行列步队，并以 Logstash 作为一个自定义消费者：
不同的是，syslog-ng 利用起来比 rsyslog 更随意马虎，性能没有 rsyslog 那么极致：例如，它只对输出进行缓冲，以是它所有的打算处理在缓冲之前就完成了，这也意味着它会给日志流带来压力。
Fluentd
Fluentd 创建的初衷紧张是尽可能的利用 JSON 作为日志输出，以是传输工具及其下贱的传输线不须要预测子字符串里面各个字段的类型。这样，它为险些所有的措辞都供应库，这也意味着，我们可以将它插入到我们自定义的程序中。
上风
和多数 Logstash 插件一样，Fluentd 插件是用 Ruby 措辞开拓的非常易于编写掩护。以是它数量很多，险些所有的源和目标存储都有插件（各个插件的成熟度也不太一样）。这也意味这我们可以用 Fluentd 来串联所有的东西。
劣势
由于在多数运用处景下，我们会通过 Fluentd 得到构造化的数据，它的灵巧性并不好。但是我们仍旧可以通过正则表达式，来解析非构造化的数据。只管，性能在大多数场景下都很好，但它并不是最好的，和 syslog-ng 一样，它的缓冲只存在与输出端，单线程核心以及 Ruby GIL 实现的插件意味着它大的节点下性能是受限的，不过，它的资源花费在大多数场景下是可以接管的。对付小的或者嵌入式的设备，可能须要看看 Fluent Bit，它和 Fluentd 的关系与 Filebeat 和 Logstash 之间的关系类似
范例运用处景
Fluentd 在日志的数据源和目标存储各种各样时非常得当，由于它有很多插件。而且，如果大多数数据源都是自定义的运用，以是可以创造用 fluentd 的库要比将日志库与其他传输工具结合起来要随意马虎很多。特殊是在我们的运用是多种措辞编写的时候，即我们利用了多种日志库，日志的行为也不太一样。
结论
工具的选择由利用场景决定
参考
参考来源:
Logstash Alternatives
本文转自:https://www.cnblogs.com/richaaaard/p/6109595.html
