上一章節我們逐步説明日誌從源設備傳輸到Log360控制枱、直至可供分析的完整流程。點此查看文章詳情。

為了呈現該架構在動態環境中的運行表現，本節將探討多個企業常見場景。這些示例將展示系統在應對組件故障、工作負載變化及業務需求演進時的設計邏輯與響應方式。

場景1：冗餘部署中的處理器節點故障

案例：某企業部署了兩台處理器，且兩台處理器均配置了相同角色（處理引擎、日誌隊列引擎、搜索引擎）。其中一台處理器發生硬件故障並下線。

解決方案：剩餘的活躍處理器會無縫接管全部工作負載。訪問網關集羣（Access Gateway Cluster）會自動停止向故障節點轉發日誌。由於隊列主題（queue topics）和Elasticsearch數據已在集羣中實現副本備份，因此不會出現日誌丟失，搜索功能也能保持在線，確保服務連續性。

場景2：承擔唯一專屬角色的節點故障

案例：為處理高負載的規則運算，企業將關聯引擎（Correlation Engine）角色分配給了一台專屬的獨立處理器，而該處理器發生故障。

解決方案：實時關聯分析會暫時暫停，但其他節點仍會繼續執行日誌攝入、隊列緩存和索引建立操作，因此不會造成數據丟失。當故障處理器恢復正常，或關聯引擎角色被重新分配至另一台活躍處理器後，系統會從隊列中處理積壓的事件，確保不會遺漏任何安全威脅。

場景3：擴展特定功能以滿足需求

案例：分析人員反饋，在峯值調查時段，日誌搜索查詢速度變慢，給安全團隊造成了瓶頸。

解決方案：企業可通過橫向擴展（horizontally scale）解決該問題——新增一台處理器節點，併為其分配專屬的搜索引擎角色。此舉可將資源密集型的搜索功能與日誌攝入、日誌處理節點隔離開來。現有Elasticsearch集羣會自動將搜索工作負載分配至新節點，查詢性能隨即得到提升。

場景4：適配“僅日誌轉發”需求

案例：某企業決定將安全分析功能集中到另一款工具中，目前僅需Log360從各遠程站點收集、解析並轉發日誌。

解決方案：通過主要處理器（Primary Processor）重新配置角色，可簡化架構。具體操作包括：禁用關聯分析（Correlation）、搜索（Search）、告警（Alerts）等角色，將處理器專屬用於處理引擎（Processing Engine）、日誌隊列引擎（Log Queue Engine）和日誌轉發（Log Forwarding）角色。此外，可停用不必要的節點以降低成本，從而將Log360高效轉型為高可擴展的日誌轉發管道。

場景5：主要處理器（Primary Processor）故障

案例：負責集羣管理與配置任務的主要處理器意外下線。

解決方案：其他所有安全運營工作（如數據收集、處理、搜索、告警）會在其餘處理器節點上繼續運行，不受任何中斷影響。儘管新增處理器等管理類任務會暫時暫停，但安全監控功能完全不受影響。

後續步驟

瞭解Log360的架構原理後，下一步需規劃具體的部署方案。可登錄卓豪官網瞭解更多詳細信息。