ELK協議棧的網絡容錯體系結構

Question

這只是幾天我熟悉ELK Stack。我們試圖在我們的企業應用程序中使用它，但有一些架構問題。我見過&閱讀了一些ELK及其架構的使用案例，especially in 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

請讓我知道這個架構是否有意義？
如果不是這樣，任何其他容錯架構將受到歡迎:)

Answer 1

答案取決於允許的風險程度，您可能會遇到的風險以及您預計發生事件的時間持續。

如果您寫入本地文件，則可以使用Filebeat將文件發送到遠程logstash。如果該logstash（或下游Elasticsearch羣集）應用反壓，則filebeat將放慢速度或停止發送日誌。這爲您提供了遠程機器上的分佈式緩存（不需要代理）。缺點是，如果中斷時間很長，日誌文件可能會從filebeat的全局模式下轉出，然後永遠不會出貨。

有了多個logstash實例，您可以配置filebeat以發送到它們的列表，從而提供一些生存能力。如果你有「一次性」事件（比如snmptraps，syslog等），你會想要再考慮一下可能的中斷。

我曾經爲這些類型的事件運行一個單獨的logstash實例，這些事件會饋入redis。然後，主Logstash（在啓動時）將從隊列中讀取並處理事件。這使我可以啓動新的logstash配置，而不用擔心丟失事件。現在，我嘗試將事件寫入文件（使用snmptrapd等），而不依賴任何運行24x7x365的logstash。