我們原來的問題
去年，我們遇到了一個問題，一台伺服器上的惡意軟體會向我們的中央 Graylog 伺服器發送大量訊息，導致其他應用程式出現問題。
主要問題是來自其他應用程式的較舊的有用訊息比正常情況更早被清除，索引被來自惡意應用程式的無用訊息填滿。
我建議的修復方法是為每個應用程式提供自己的索引，這樣任何應用程式都不會耗盡任何其他應用程式的日誌儲存空間。這不需要對應用程式本身進行任何更改，只需要在 Graylog 內部進行更改。然而，我們什麼也沒做，因為正在計劃一個新的基於 kubernetes 的 Graylog 解決方案。
我們提供的解決方案
快轉到現在，我們正在調試更換 Graylog 系統。
最初我們被告知每個應用程式都有自己獨立的graylog伺服器（負載平衡器、gelf端點、graylog節點、彈性搜尋叢集）和graylog前端網站。
問題是，不同應用程式之間存在複雜的關係，並且必須轉到不同的graylog Web伺服器來取得來自不同應用程式的日誌（graylog-application1.site用於來自application1的日誌，graylog-application2.site用於來自application2的日誌，而不是而不僅僅是訪問graylog.site）將使跨應用程式搜尋變得非常困難。
修改後的解決方案
指出這一點後，提出了一種解決方案，根據應用程式需要一起搜尋的可能性將它們分組在一起，因此現在我們期望每個群組都有單獨的Graylog 伺服器（應用程式的application-group-a. site 1 和 3，以及應用程式 2、4 和 5 等的 application-group-b.site）。
我想知道這是否必要或充分。
這意味著許多可能的跨應用程式搜尋將很容易完成，但一些最難解決的支援問題是那些不太明顯的跨應用程式邊界的問題，並且這些搜尋將不再那麼容易（實際上可能如果您不知道涉及哪個應用程序，這是不可能的）。
人們認為，僅在單一中央graylog伺服器上擁有單獨的索引並不能在應用程式群組之間提供足夠的隔離。他們希望確保來自一個應用程式的訊息進入永遠不會幹擾來自其他應用程式的訊息進入，因此他們希望群組之間完全隔離。
我的問題是，它不會幫助群組內的應用程式變得流氓並向群組graylog伺服器發送垃圾郵件。如果我們能找到防止組內拒絕服務解決方案的解決方案，那麼我們也將擁有單一集中式 Graylog 服務的解決方案。
我認為，使用更多負載平衡的graylog節點、更多彈性搜尋節點、更多GELF端點等水平擴展單一中央服務將是比擁有數十個graylog伺服器更好的解決方案。
問題
當單獨的graylog伺服器全部託管在同一個kubernetes叢集上時，它們實際上會提供人們似乎想要的隔離等級（拒絕服務緩解）嗎？
我們能否使用單一中央 Graylog 伺服器提供與單獨的群組 Graylog 伺服器類似或更好的隔離等級？
其他組織是否以這種方式使用 Graylog，並擁有許多前端網站，或者是否需要一個中央網站來存取所有日誌？
本質上，我希望要么說服自己，我什麼都不用擔心，而且這個解決方案很常見；或說服人們我們正在考慮的事情與最佳實踐相悖的論點，我們真的不應該這樣做。
我真的很想找到一個適合每個人的解決方案，但在我看來，目前我們提出的解決方案似乎是把嬰兒和洗澡水一起倒掉了。
答案1
您對 Graylog 設定架構的擔憂和問題是非常合理的。找到一個平衡隔離和資源管理需求與易用性和可管理性的解決方案非常重要。讓我們像 Kris Kross 一樣分解它！
1. 當單獨的 Graylog 伺服器全部託管在同一個 Kubernetes 叢集上時，它們實際上會提供人們想要的隔離等級（拒絕服務緩解）嗎？
在同一 Kubernetes 叢集上運行的單獨 Graylog 伺服器可以提供一定程度的隔離，但重要的是要了解它們仍在叢集層級共享資源，包括網路頻寬、儲存以及潛在的 CPU 和記憶體。如果群組中的一個應用程式出現惡意行為並開始發送垃圾郵件，則可能會因資源爭用而影響同一叢集上其他 Graylog 伺服器的效能。雖然 Kubernetes 提供資源管理功能，但它並不是防止資源相關問題的靈丹妙藥。
2. 我們能否使用單一中央 Graylog 伺服器提供與單獨的 Graylog 伺服器群組類似或更好的隔離等級？
單一中央 Graylog 伺服器可以使用單獨的索引在應用程式之間提供隔離，但正如您所提到的，它可能無法防止惡意應用程式使伺服器過載並導致其他應用程式出現問題。為了緩解這種情況，您可以考慮對產生日誌訊息的輸入或來源實施更嚴格的速率限制和限制策略。此外，您可以水平擴展中央 Graylog 伺服器以處理增加的負載，這比管理多個單獨的伺服器更具成本效益。
3. 其他組織是否以這種方式使用 Graylog，有許多前端網站，或者是否需要一個中央網站來存取所有日誌？
選擇針對不同的 Graylog 實例使用多個前端網站還是單一中央網站取決於組織的特定需求和偏好。這兩種方法都是有效的，而且各有優點和優點和缺點。
多個前端網站：當不同的團隊或應用程式需要單獨的 Graylog 實例以更好地隔離、控制和組織時，此方法適用。它可以簡化存取控制並為不同團隊提供自主權。然而，它可能需要用戶在不同介面之間切換以進行跨應用程式搜尋。
單一中央網站：用於存取所有日誌的單一中央網站提供了整個日誌基礎設施的統一視圖，使跨應用程式搜尋變得更加容易。這種方法簡化了使用者訪問，但可能需要更強大的存取控制和權限管理，以確保不同團隊或應用程式之間的資料分離。
最終，這些方法之間的選擇取決於您的組織在隔離、易用性、資源管理以及應用程式和團隊的特定要求方面的優先順序。
要找到適合所有人的平衡解決方案，請考慮以下因素：
- 在每個 Graylog 實例中實施嚴格的速率限制和節流策略，以防止惡意應用程式壓垮系統。
- 監控所有 Graylog 實例的資源使用情況和效能並發出警報，以主動偵測和解決問題。
- 記錄並向所有團隊傳達日誌管理和使用的最佳實踐。
- 繼續探索具有適當資源擴展和存取控制機制的集中式 Graylog 解決方案的可能性。
總而言之，最好的方法可能涉及組合。您可能會發現自己對應用程式的邏輯群組使用單獨的 Graylog 實例，同時實施強大的資源管理和監控實踐，以確保日誌管理基礎架構的整體穩定性。讓不同團隊的利害關係人參與決策過程也很重要，以確保所選的解決方案符合他們的需求和期望，這只是一個避免問題的建議，你知道嗎？ ;)
答案2
Graylog（以及類似產品）提供的最大優勢不是孤立的日誌存儲，而是不同日誌來源和記錄事件之間的關聯。透過使用多個單獨的 Graylog 伺服器，每個伺服器收集不同的來源，多重來源關聯變得更加困難。
我建議使用單一 Graylog 伺服器（或叢集多節點設置，如果單一節點不夠）和多個特定索引，以及不同的（且適當的）輪換策略。您可以透過適當的方式將流量路由到這些索引直播規則（並選擇“從預設流中刪除匹配項”）。