我读了一篇关于设置Logstash、Elasticsearch和Kibana的博客文章，作者建议使用NXLog从不同的机器运送日志。"Logstash Book"中介绍的一个典型的分布式场景展示了Logstash如何同时用于运输和索引角色。我们目前正在试验Logstash，并将其设置为将日志运送到Elasticsearch。所以我想知道为什么人们选择NXLog作为Logstash的日志发货人，而不是在两端都使用Logstash。
logstash转发器项目，以前被称为"Lumberjack"，解释如下：
资源使用问题
感知问题：一些用户将logstash版本视为"大型"或对Java有着普遍的恐惧。
实际问题：目前，Logstash的运行占用空间对诸如EC2 micro之类的配置不足的系统不友好实例；在其他系统上它是好的。此项目将存在到问题得到解决。
运输问题
很少有日志传输机制提供安全性、低延迟和可靠性
该项目使用的伐木工人协议旨在提供安全、低延迟、低成本的网络传输协议资源使用和可靠。
Logstash发货人实例并不是特别是重量级的，但如果您的机器只有1-2GB的RAM，那么很难随意将几百MB分配给另一个JVM实例。
另一个考虑因素是：如果您的发货人节点运行的操作系统不受Logstash支持，该怎么办？Logstash现在可以在Windows上运行，但它仍然存在缺陷。我不能特别保证NXLog在这方面，但我认为它是一个受欢迎的选择。
我们已经使用RSyslog而不是LogStash实现了发货，因为我们希望在可能的情况下让java远离我们的主机。它使日志主机/文件服务器上的LogStash配置稍微复杂一些，但与在中央文件服务器上拆分日志相比，不必在前端主机上跟上Java安全升级的步伐更令人痛苦。
我使用nxlog，因为它与源、平台和目的地无关。
作为一个安全团队，我们需要来自各地的大量数据，但不想同时负责处理操作数据。在数据被传递到logstash或splunk之后检索数据也是不可行的。因此，nxlog让我们可以大快朵颐：我们将数据发送到安全收集基础设施，并允许运营团队将部分或全部数据（甚至是我们不感兴趣的数据）发送到他们想要的任何地方。
它还满足了将基础设施作为可更换组件的核心要求。。。如果出现更好的情况，我们可以更换单个组件（例如用flink替换storm），而不必更改整个基础设施（就像我们远离splink一样）