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。