本節將深入剖析 Log360 可擴展架構的核心組件，闡述各組件的定義、功能及其對系統可擴展性的直接作用。

1. 日誌處理集羣

日誌處理集羣採用分佈式架構，為每個日誌處理器分配相應功能以實現負載均衡，取代了傳統的單服務器部署模式，由多個處理器共同分擔工作負載。

説明
節點指安裝有 Log360 的獨立服務器，我們將其稱為日誌處理器。集羣則是由多個此類獨立節點通過網絡連接組成的系統，可作為單一高性能單元進行統一管理。

日誌處理器需統一部署在單一中心位置。在分佈式架構中，遠端站點僅需部署代理程序，由代理收集日誌並轉發至中心處理器，再由中心處理器完成日誌分析與存儲。

集羣內所有處理器必須安裝同一版本的 Log360。首次安裝的節點將作為主處理器，集羣的各類操作（如添加、編輯、刪除處理器）均需通過主處理器執行。用户可登錄任意處理器，查看集中式監控面板並監控集羣運行狀態。

日誌處理集羣如何實現負載分配與水平擴展
日誌採集：為確保工作負載在所有處理器間均勻分配，代理程序會將日誌上傳至可用的處理器節點，避免單一節點過載，提升系統整體穩定性。當向集羣中添加新節點時，代理配置會同步更新，從而實現系統採集能力的水平擴展。

基於角色專業化的集羣運行機制

不同安全功能對系統資源的需求存在差異。例如，日誌採集屬於 CPU 密集型任務，而日誌檢索與關聯分析則對內存要求較高。在大型部署環境中，若由單個處理器同時承擔所有任務，極易引發性能衝突，比如高資源消耗的檢索查詢可能導致關鍵的日誌採集任務運行緩慢。

Log360 的可擴展性設計原理
基於角色的專業化分工：這種多層級的角色分工模式，通過為每個日誌處理器分配特定功能，有效解決了性能瓶頸問題。該模式在高性能數據平台中已得到驗證，能夠實現資源隔離，避免單一功能運行對其他功能造成影響，從而保障系統運行的穩定性與可預測性。

同時，該架構支持針對性擴展，即僅對負載壓力過大的系統模塊進行擴容。例如，當檢索速度變慢時，只需增加更多專用於“搜索引擎”角色的節點，無需對採集節點進行調整，不會影響日誌採集任務。

在可擴展部署模式下，Log360 支持以下角色劃分：

預設角色
處理引擎：對已解析的日誌進行數據豐富化處理，默認負責日誌轉發、告警生成及日誌歸檔。
日誌隊列引擎：管理組件間的事件流轉，防止數據丟失。
關聯分析引擎：基於安全規則對事件進行檢測分析。
搜索引擎：對數據建立索引並存儲至 Elasticsearch，同時響應用户檢索請求。

可選專業角色/自定義角色
以下功能可從處理引擎中剝離，部署在專用節點上，以提升系統靈活性與性能：

告警引擎：根據常規告警規則和關聯分析規則生成告警通知。
日誌轉發器：將日誌發送至外部工具或存儲介質，供後續分析與存檔。
日誌歸檔器：根據預設的日誌保留策略，完成日誌的長期存儲。

説明
一旦將上述功能配置為獨立的自定義角色，處理引擎將不再承擔對應任務。

如需根據企業基礎設施情況，高效規劃節點擴容與角色分配方案，請參考《容量規劃手冊》。

2. 隊列引擎

Log360 的隊列層是組件間數據流轉的核心通道，能夠高效處理海量日誌數據，即使在系統故障或負載激增的情況下，也可確保數據零丟失。該隊列系統支持 Log360 內部各模塊之間，以高可靠性、高傳輸速率完成消息（日誌數據）的收發。

隊列層核心概念該架構基於主題（Topic） 實現日誌流轉的隊列管理，隊列引擎的核心組件説明如下：

主題
主題相當於一個分類文件夾，用於存放同類消息（數據）。例如，一個主題可存儲原始日誌，另一個主題存儲已處理日誌，還有一個主題專門存儲告警數據。

Log360 包含以下核心主題：

•數據豐富化主題
•關聯分析主題
•告警主題
•日誌轉發主題
•操作行為主題
•安全事件主題

分區
分區功能將單個主題拆分為多個數據分片，允許多個進程同時處理同一主題的數據，從而提升處理速度與系統可擴展性。其原理類似於將一個長隊列拆分為多個短隊列，實現並行處理，提升整體效率。

副本機制
每個分區的數據都會同步複製到多個處理器節點。當某一處理器故障時，可由其他節點的副本數據接替工作，確保系統高可用性與容錯能力。

消息代理
消息代理是集羣中的獨立節點，負責數據存儲及消息收發請求的處理。在 Log360 中，隊列集羣由分佈在各處理器節點上的多個消息代理協同組成。每個消息代理並非存儲所有主題數據，而是通過智能分配機制，將主題及其分區數據分散存儲在不同代理節點上，以實現性能優化與負載均衡。

生產者
生產者是向隊列中發送數據的組件。例如，在 Log360 中，處理引擎會將日誌數據發送至上述各類隊列主題，承擔生產者的角色。

消費者
消費者是從隊列中讀取數據的組件。例如，在 Log360 中，關聯分析引擎與告警引擎會讀取相關數據流，進行威脅檢測與處理，承擔消費者的角色。

控制節點
在多節點部署架構中，會指定一個專用的消息代理作為控制節點，負責將分區分配至各個消息代理，並監控集羣的運行健康狀態。

數據持久性
隊列會按照預設時長保存所有消息數據，確保故障下線的節點在恢復後，能夠回溯並補全缺失的數據。

隊列集羣核心價值
綜上所述，隊列集羣實現了以下關鍵能力：

數據零丟失：即使處理器節點發生臨時性故障，也不會造成數據丟失。
組件解耦：將系統拆分為數據發送方（生產者）與接收方（消費者），各組件可獨立運行。
彈性擴展：當日志數據量增長時，可通過增加消息代理節點實現處理能力擴容。
海量數據處理：高效支撐多租户、混合雲及大型企業環境下的日誌處理需求。
隊列集羣是 Log360 構建高速、容錯型數據傳輸通道的核心支撐。

3. 檢索層

Log360 的檢索層基於 Elasticsearch 構建，是系統的索引數據存儲與檢索引擎。

核心作用與功能
數據索引：已解析和豐富化的日誌數據會被髮送至 Elasticsearch 建立索引。
快速檢索與實時查詢：基於 Elasticsearch 的強大能力，實現海量數據集的高速檢索與實時查詢。

4. 存儲層

Log360 的存儲層負責根據數據的使用場景與生命週期階段，選擇不同存儲類型完成數據的留存與歸檔。

存儲類型

熱存儲

￮基於 Elasticsearch 索引實現，是系統的熱存儲模塊。
￮高頻查詢的數據會存儲於此，以保障快速訪問，數據留存時長可按需配置。
￮寫入組件：搜索引擎、關聯分析引擎、告警引擎
￮訪問組件：搜索引擎（執行檢索查詢時）

冷存儲（歸檔存儲）

￮當日志數據老化後，可從熱存儲遷移至共享歸檔存儲。
￮滿足合規要求，支持日誌的長期留存。
￮數據仍可檢索，但查詢性能會低於熱存儲。
￮寫入組件：日誌歸檔器/處理引擎
￮訪問組件：搜索引擎

通用數據庫（關係型數據庫：PostgreSQL/MSSQL）

￮用於存儲系統元數據、配置信息、告警規則配置、數據豐富化元數據等。
￮不承擔日誌數據存儲任務，但對產品內部運行及組件間通信至關重要。
￮寫入組件：所有處理器節點
￮訪問組件：所有處理器節點

處理器共享存儲

￮用於實現集羣內多個處理器節點間的數據交換與協同工作。
￮支持中間文件傳輸、節點運行狀態同步及信息共享。
￮是保障多節點部署環境下系統穩定運行的關鍵組件。
￮寫入組件：所有處理器節點
￮訪問組件：所有處理器節點

支撐存儲層的核心主題

以下為關鍵隊列主題及其與存儲層的交互邏輯：

存儲層核心優勢

保障數據留存與可恢復性。
實現實時數據傳輸通道與長期歸檔系統的無縫銜接。
通過留存歷史數據，滿足相關合規性法規要求。
下一節將繼續分享關於日誌如何被攝取、處理和存儲的概述，並以部署場景進行説明，以及Log360中的架構實踐的常見場景。