Я познакомился с ELK Stack всего через несколько дней. Мы пытаемся использовать его в наших корпоративных приложениях, но у нас есть некоторые архитектурные проблемы. Я видел и читал несколько примеров использования ELK и их архитектур, особенно в linkedin, но никто не обсуждал потенциальное влияние сетевых ошибок на его / ее архитектуру.
В традиционных приложениях, журналы которых обычно записываются в файлы, единственная причина, которая может вызвать сбой системы, - это Disk is Full ошибка, которая действительно встречается редко. Но в централизованной системе журналов, в которой журналы отправляются через сеть, поскольку сетевые ошибки очень распространены, я думаю, что система очень подвержена сбоям !! Особенно в / для корпуса с ненадежной сетью.
Более того, как я видел во многих ELK случаях использования, один экземпляр JMS Provider или, другими словами, Pub/Sub Provider, например Kafka или Redis, используется вместе с ELK. Я думаю, что помимо предыдущей проблемы, JMS Provider является single point of failure в этих архитектурах! Если только это не будет сгруппировано.
Я думаю, что мы можем избавиться от обеих проблем, если мы будем использовать JMS Provider как Kafka рядом с каждым Shipper[s] на одном узле следующим образом (по одному Kafka для каждого узла):
((log-generator)+ (logstash)? Kafka)* -> Logstash -> Elasticsearch -> Kibana
Пожалуйста, дайте мне знать, имеет ли эта архитектура смысл?
Если нет, любая другая отказоустойчивая архитектура будет приветствоваться :)
