概述常见的日志采集工具有Logstash、Filebeat、Fluentd、Logagent、rsyslog等，那么它们有什么区别呢？什么情况下我们应该使用Whichtool？LogstashLogstash是一个具有实时流水线能力的开源数据收集引擎。Logstash可以动态统一来自不同来源的数据，并将数据规范化到您选择的目的地。优点Logstash的主要优点是它的灵活性，主要是因为它有很多插件、详细的文档和简单明了的配置格式，使其可以应用于多种场景。对于几乎任何问题，我们基本上都可以在网上找到很多资源。缺点Logstash的致命问题是它的性能和资源消耗（默认堆大小为1GB）。虽然它的性能近年来有了很大的提高，但仍然比它的替代品慢得多。这是Logstash与rsyslog的性能比较以及Logstash与filebeat的性能比较。在数据量很大的情况下，这可能是个问题。另一个问题是它目前不支持缓存。目前典型的替代方案是使用Redis或Kafka作为中央缓冲池：典型应用场景由于Logstash自身的灵活性和网络上的丰富数据，Logstash适合用于原型验证阶段，或者分析非常复杂的时候。不管服务器资源如何，如果服务器的性能足够好，我们也可以在每个服务器上安装Logstash。我们也不需要使用缓冲，因为文件本身有缓冲行为，Logstash会记住最后处理的位置。如果服务器性能较差，不建议每台服务器都安装Logstash，所以需要一个轻量级的日志传输工具，通过一台或多台Logstash中心服务器将数据从服务器传输到Elasticsearch：随着日志项目的推进，可能由于性能或成本问题，有必要调整日志传输方法(logshipper)。在判断Logstash的性能是否足够好时，重要的是要对吞吐量需求有一个准确的估计，这也决定了Logstash需要投入多少硬件资源。Filebeat作为Beats家族的一员，是一款轻量级日志传输工具，弥补了Logstash的不足：Filebeat作为一款轻量级日志传输工具，可以将日志推送到中央Logstash。在5.x版本中，Elasticsearch具有分析功能（如Logstash过滤器）——摄取。这也意味着数据可以通过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消费者）可以进一步丰富和转发。这假设所选的下游交付工具满足我们的功能和性能要求。FluentdFluentd的初衷是尽可能使用JSON作为日志输出，因此传输工具及其下游传输线路不需要猜测子字符串中每个字段的类型。通过这种方式，它提供了几乎所有语言的库，这也意味着我们可以将它插入到我们的自定义程序中。优点与大多数Logstash插件一样，Fluentd插件采用Ruby语言开发，非常易于编写和维护。所以数量很多，几乎所有的源存储和目标存储都有插件（各个插件的成熟度不一样）。这也意味着我们可以使用Fluentd将所有内容连接在一起。缺点是在大多数应用场景中，我们会通过Fluentd获取结构化数据，其灵活性不好。但是我们仍然可以通过正则表达式来解析非结构化数据。虽然，在大多数场景下性能都不错，但并不完美，和syslog-ng一样，它的缓冲只存在于输出端，插件的单线程核心和RubyGIL实现意味着它在巨大节点下的性能有限，但其资源消耗在大多数场景下是可以接受的。对于小型或嵌入式设备，您可能需要查看FluentBit，它与Fluentd的关系类似于Filebeat与Logstash的关系。典型应用场景Fluentd非常适合日志的数据源和目标存储多种多样的情况，因为它有很多插件。此外，如果大多数数据源是自定义应用程序，您可能会发现使用fluentd的库比将日志库与其他传输工具组合起来更容易。特别是当我们的应用程序是用多种语言编写的时候，即使我们使用了多个日志库，日志的行为也是不同的。LogagentLogagent是Sematext提供的传输工具，用于将日志传输到Logsene（一个基于SaaS平台的ElasticsearchAPI）。因为Logsene会暴露ElasticsearchAPI，所以Logagent可以方便的将数据推送到Elasticsearch。优点可以获取/var/log下的所有信息，解析各种格式（Elasticsearch、Solr、MongoDB、ApacheHTTPD等），可以屏蔽敏感数据信息，如个人身份信息（PII）、出生日期、信用卡号等等。它还可以基于IP对地理位置信息（例如，访问日志）进行GeoIP丰富。同样，它又轻又快，可以放入任何日志块中。在新的2.0版本中，以第三方node.js的模块化方式增加了对输入输出处理插件的支持。重要的是Logagent具有本地缓冲，因此与Logstash不同，当数据传输目的地不可用时，日志就会丢失。缺点尽管Logagent有一些有趣的功能（例如，接收Heroku或CloudFoundry日志），但它不如Logstash灵活。典型应用场景Logagent作为一款无所不能（提取、解析、缓冲、传输）的传输工具，值得选择。阿里云日志服务的生产者Logtail目前运行在阿里巴巴集团内部的机器上。经过三年多的考验，目前为阿里公有云用户提供日志采集服务。采用C++语言实现，在稳定性、资源控制、管理等方面下了很大功夫，性能良好。相对于logstash和fluentd的社区支持，logtail功能单一，侧重于日志收集。优势Logtail占用机器CPU和内存资源最少，结合阿里云日志服务的端到端体验好。缺点Logtail目前支持对特定日志类型的弱解析，需要后续补充。rsyslog大多数Linux发行版上的默认syslog守护进程，rsyslog可以做的不仅仅是从syslog套接字读取日志并将它们写入/var/log/messages。它可以提取文件、解析、缓冲（磁盘和内存），并将它们传输到多个目的地，包括Elasticsearch。如何处理Apache和syslog可以在这里找到。优点rsyslog是经过测试的最快的传输方式。如果您只是将它用作简单的路由器/托运器，几乎任何机器都会受到带宽限制，但它非常擅长处理解析多个规则。无论规则数量如何增加，其基于语法的模块（mmnormalize）始终线性提高其处理速度。这意味着如果有20-30条规则，比如在解析Cisco日志时，其性能可以大大超过基于正则表达式解析的grok，达到100倍（当然这也取决于grok和liblognorm版本的实现的）。它也是我们能找到的最轻的解析器，当然取决于我们配置的缓冲区。缺点rsyslog的配置成本更高（这里有一些示例），这使得两件事变得非常困难：文档难以搜索和阅读，尤其是对于不熟悉该术语的开发人员。5.x以上的版本有不同的格式（它扩展了syslogd的配置格式，同时仍然支持旧格式），虽然新格式兼容旧格式，但新功能（例如Elasticsearch输出）可用in新的配置才有效，那么旧的插件（例如，Postgres输出）只支持旧的格式。虽然rsyslog在稳定的配置中是可靠的（并且它提供了自己的多种配置，但最终都得到了相同的结果），但它有一些错误。典型应用场景rsyslog适用于那些非常轻量级的应用（应用、小型VM、Docker容器）。如果需要在其他传输（例如Logstash）中进行处理，JSON可以直接通过TCP转发，或连接到Kafka/Redis缓冲区。当我们对性能要求非常严格的时候，尤其是有多个解析规则的时候，rsyslog也是适用的。那么花更多时间研究它的配置是值得的。
