仅仅几天我就认识ELK Stack。我们试图在我们的企业应用程序中使用它，但有一些架构问题。我见过＆amp;阅读ELK及其架构especially in linkedin的一些用例，但没有人讨论过网络错误对他/她的架构的潜在影响。
在传统应用程序中，通常将日志写入文件中，导致系统崩溃的唯一原因是Disk is Full错误，这种情况非常罕见。但是在集中式日志系统中，日志是通过网络发送的，因为网络错误非常普遍，我认为系统非常容易崩溃！特别是对于网络不可靠的队伍。
此外，正如我在许多ELK个使用案例中看到的那样，JMS Provider的单个实例，或者换句话说Pub/Sub Provider Kafka或{{1} }}与Redis一起使用。我认为除了上一个问题，ELK在这些架构中是JMS Provider！除非，那将是聚集的。
我认为，如果我们在单个节点上使用single point of failure JMS Provider和每个Kafka旁边的Shipper[s]，我们可以解决这两个问题（每个Kafka一个节点）：
((log-generator)+ (logstash)? Kafka)* -> Logstash -> Elasticsearch -> Kibana
请告诉我这个架构是否有意义？
如果没有，欢迎任何其他容错架构：）
答案 0 :(得分：1)
答案取决于允许的风险程度，您可能会遇到的风险，以及您预计事件将持续多久。
如果您写入本地文件，则可以使用Filebeat将文件发送到远程logstash。如果该logstash（或下游Elasticsearch集群）应用反压，则filebeat将减慢或停止发送日志。这为您提供了远程计算机上的分布式缓存（无需代理）。缺点是，如果中断是持久的，日志文件可能会从filebeat的glob模式下旋转出来，然后它将永远不会出货。
使用多个logstash实例，您可以将filebeat配置为发送到它们的列表，从而提供一些生存性。如果你有＆＃34;一次性＆＃34;事件（如snmptraps，syslog等），你想要再考虑可能的中断。
我曾经为这些类型的事件运行一个单独的logstash实例，这些实例将提供给redis。然后，主logstash（up）将从队列中读取并处理事件。这允许我启动一个新的logstash配置，而不用担心丢失事件。这些天，我尝试将事件写入文件（使用snmptrapd等），而不是依赖于24x7x365运行的任何logstash。