ELK Stack的网络容错架构

Question

我只有几天熟悉ELK Stack 。 我们正在尝试在企业应用程序中使用它，但存在一些体系结构方面的问题。 我已经看过并阅读了ELK及其体系结构的一些用例， 尤其是在linkedin中 ，但是没有人讨论过网络错误对其体系结构的潜在影响。

在通常将日志写入文件的传统应用程序中，可能导致系统崩溃的唯一原因是“ Disk is Full错误，这种情况很少发生。 但是在通过网络发送日志的集中式日志系统中，由于网络错误非常普遍，我认为该系统极易发生崩溃！ 特别是在网络不可靠的部队中。

此外，正如我在许多ELK用例中所看到的那样，将JMS Provider的单个实例，或者换句话说，将Kafka或Redis类的Pub/Sub Provider与ELK一起使用。 我认为除了先前的问题外， JMS Provider还是这些体系结构中的single point of failure ！ 除非，否则将被聚类。

我认为，如果像下面这样在单个节点上与每个Shipper[s]一起使用像Kafka这样的JMS Provider ，则可以摆脱这两个问题（每个节点一个Kafka ）：

((log-generator)+ (logstash)? Kafka)* -> Logstash -> Elasticsearch -> Kibana

请让我知道这种架构是否有意义？
如果没有成功，将欢迎其他任何容错架构:)

Answer 1

答案取决于所允许的风险程度，您可能希望在何处遇到此类风险以及事件持续多长时间。

如果写入本地文件，则可以使用Filebeat将文件发送到远程logstash。 如果该logstash（或下游Elasticsearch群集）施加了反压力，则filebeat将减慢速度或停止发送日志。 这为您提供了远程计算机上的分布式缓存（不需要代理）。 不利的一面是，如果中断是长期的，则日志文件可能会从filebeat的glob模式下转出，然后它将永远无法发送。

对于多个logstash实例，您可以配置filebeat以将其发送到它们的列表，从而提供一些生存能力。 如果您有“一次性”事件（例如snmptraps，syslog等），则需要考虑可能的中断。

我曾经为这些类型的事件运行单独的logstash实例，这些实例将馈入redis。 然后，主logtash（启动时）将从队列中读取并处理事件。 这使我可以启动新的logstash配置，而不必担心丢失事件。 这些天来，我尝试将事件写入文件（带有snmptrapd等），而不依赖于任何运行24x7x365的logstash。