我一直在研究 ELK 堆栈或 RabbitMQ，以取代一个自主开发的系统，该系统可以接收大量文件（每小时 2 亿到 3 亿个），然后根据名称和内容将它们发送到各个位置，并在本地存储副本。（基本上就是 ELK）
然而，我对所需的复杂性和硬件占用空间感到有点不满意。
对于这种任务，RabbitMQ 与 ELK 堆栈相比有哪些优势？在我看来，ELK 可能有点过头了，但我对 RabbitMQ 不够熟悉，无法给出明确的结论。
答案1
我的数学计算表明，每秒大约有 83K 个事件。这可不少。
我不太清楚你为什么要将 RMQ 和 ELK 分开，因为 RMQ 可以是 ELK 的一个组件。事实上，据我所知，非常大的部署肯定使用 Rabbit 之类的 AQMP 解决方案或 Kafka 之类的解决方案来提供事件生成和解析层之间的缓冲，以及为多个消费者提供信息。
可以处理您正在考虑的事件流的通用大规模管道：
- 发货方将日志发送到中央队列。发货方可以是 FileBeat、Logstash 本身，也可以是其他完全不同的发货方。
- 队列系统，无论它是什么。可以是 Redis、RabbitMQ、Kafka 或其他。
- 解析层。一组 Logstash 节点，从队列中提取事件，对其进行处理，然后将其发送到下一阶段。
- 这可以水平扩展。只要您的队列系统能够跟上，您就可以继续在此处添加解析器。在我们的系统中，使用我们的过滤规则，我们可以每核每秒处理 2K 个事件。您的系统会有所不同。
- 如果您利用队列中的通道，您甚至可以根据工作负载的分配方式拥有多个解析层。
- 此组 CPU 使用率较高。RAM 使用率有多高取决于您的过滤器最终有多复杂。
- 存储层。在经典 ELK 中，这是 ElasticSearch。不过，它不一定非得如此。
- 每小时处理 3 亿个事件的 ElasticSearch 集群将非常庞大。这是无法回避的。规模大小取决于您想要保留数据多长时间。
- 听起来您的消费者正在等待文件。这也可以做到。将处理过的事件（只是 JSON）发送到另一个排队系统以供其他系统使用也是如此。
这种架构的优点在于您无需将过滤逻辑放在执行生产工作的资源上。它还将 ElasticSearch 的摄取问题简化为来自 Logstash 解析层的大量请求，而不是来自生产资源的较小摄取批次。
这还在您的日志存档 (ElasticSearch) 和生产资源之间提供了一些安全隔离。如果其中一个资源遭到恶意攻击，拥有队列缓冲区意味着他们无法直接清除 ElasticSearch 中的存在。如果您的公司中有安全组织，那么这一点很重要，而且每小时有 3 亿个事件，您可能足够大到拥有一个这样的组织。
Rabbit 系统存在的问题主要在于缺少一些功能。Rabbit 是一个排队系统，它本身不提供任何方法来转换数据（ELK 中的 L）或存储数据以供显示（ELK 中的 E 和 K）。无法显示其存储内容的日志归档系统不是一个好的日志归档系统。
答案2
大部分情况下我都同意 @sysadmin1138 的观点，但我想提醒你不要比较两个截然不同的东西。ELK 是三个独立应用程序的实现，它们提供日志聚合解决方案（Splunk 的 F/OSS 竞争对手），其中 RabbitMQ 是一个消息队列。
听起来你有一个非常具体的应用程序工作流程，你所做的任何事情都需要大量的工程设计。你可以大概弯曲 ELK 以满足您的需求，但正如 sysadmin1138 所说，任何具有该工作负载的系统都需要适当的扩展才能满足容量和 HA 要求。
ELK 和 RabbitMQ 的扩展性非常好，但需要一定的专业知识才能有效管理。话虽如此，如果你没有使用和管理任何规模的 ELK 集群（比如至少如果您的 ES 节点数超过 5 个，则可能需要避免将 ELK 用作非预期用途的拼凑系统。
根据收到的消息类型以及处理结果的位置，我认为最好使用 MQ 集群和应用程序池来处理作业并执行这些作业。但目前，您谈论的是一个重大项目，可能需要熟悉您的业务需求和工作流程的软件架构师和运营架构师的参与。（即比 ServerFault 问题更复杂。）