OSSIM中分佈式消息隊列應用

OSSIM中分佈式消息隊列應用

 

1. 消息隊列處理

企業日誌數量正在以指數級形式高速增加，日誌數據的具備海量、多樣、異構等特色，基於傳統的單一節點混合式安裝的OSSIM平臺（指OSSIM 4.4及如下系統），沒法知足海量日誌分析要求。在OSSIM 4.4之後的系統中增長了中間件RabbitMQ，可經過RabbitMQ將系統中各組件解除耦合，避免了系統中運行模塊的影響（例如MySQL的寫操做等），這樣設計可實現分佈式日誌分析平臺的要求。

在網絡出現故障前或故障過程當中，各類設備和服務器會發送大量日誌到日誌服務器，在原先的設計中，這樣的日誌會直接寫入數據庫或者/var/log的某個文件中，在故障狀態下的高併發情形下，會對數據庫服務器形成巨大的壓力，這是在進行日誌查詢操做時，變得相應延遲加重，很容易就超過了系統的最大負載。

如圖1-42中所示爲早期日誌收集的方案，在圖中PHP腳本從數據庫中讀取數據的典型流程，此圖包括打開數據庫鏈接、運行任意SQL和語句、讀取SQL語句找到的結果、關閉數據庫鏈接，最後在HTML頁面上將所或內容顯示給用戶。
 

上述實例中，每一個步驟都存在瓶頸，數據庫可能未調整爲最佳運行狀態，SQL語句使用的數據表可能未被優化，其中還有不少須要管理員注意的地方。若是沒有緩存，用戶在每次請求PHP腳本時都會碰到問題，每次都會致使性能下降。若是使用緩存來存儲SQL語句的結果，這種性能的損耗將不復存在。

如何解決這種問題呢，在OSSIM中採用異步操做的方式，其核心思想就是消息隊列(在OSSIM系統中，消息（Message）是由通訊的雙方所須要傳遞的日誌消息)，經過消息隊列，將短期高併發產生的日誌消息，存儲在消息隊列中，從而削平高峯期的併發事務，這樣能夠有效抵禦大量涌入的日誌，對單機數據庫系統的衝擊，也就相對改善數據庫系統性能。

以OSSIM中的SIEM事件存儲來講明問題，設備將日誌發送到Sensor，通過歸一化處理以後發往OSSIM Server，關聯引擎在對其繼續加工，會同時將數個任務收集事件寫到數據庫，所以數據庫寫入量很大，當同時查詢時併發操做將嚴重佔用有限的I/O通道。

因爲關聯引擎的業務邏輯的處理比較複雜，每每MySQL數據庫的寫操做量更大，因此在OSSIM4.0以前系統中沒有采用消息隊列時，大負荷時每每系統響應遲緩。

但OSSIM 4.4 以後採用消息隊列的思想，重構了系統以後，加入了消息隊列服務器，結構如圖1-43所示。
 

消息隊列服務器中有一個進程單獨對消息隊列進行處理，首先判斷消息隊列中是否有待處理的消息，若是有的話，那麼將其取出，並進行相應地處理。消息隊列處理流程如圖1-44所示，就這樣經過消息隊列將高併發用戶請求進行異步操做，而後逐一對消息隊列中進行出隊同步操做，也避免了併發控制的難題。

消息隊列只是解決併發問題的其中一種方式，在OSSIM中每每須要結合多種不一樣的技術方式來共同解決，好比負載均衡、反向代理等方案。這裏，雖然以異常日誌爲例，可是"麻雀雖小五臟俱全"，日誌寫入文件的高併發操做也一樣適用於數據庫的高併發，因此研究該案例具備必定指導意義。

2  RabbitMQ

RabbitMQ是實現AMQP（高級消息隊列協議）消息中間件的一種，它是消息中間件的開發標準，與平臺無關，現用於OSSIM分佈式系統中存儲轉發消息，其工做原理如圖1-45所示。
 

爲何要使用RabbitMQ？在高併發狀況下RabbitMQ在處理髮送和接收請求時響應很是快速，並且對其性能調優後，系統響應速度還會有所提升。RabbitMQ使用Erlang編寫的AMQP 服務器，而AMQP基於客戶端/代理模式。

在大數據日誌分析應用中，咱們常將OSSIM作成集羣模式，由於這樣可使用RabbitMQ的集羣功能。另外，RabbitMQ中集羣中有兩種節點，內存節點與磁盤節。對於每一個Rabbitmq 節點，根據日誌種類創建相應的隊列，而且根據日誌種類的名稱創建exchange的key值，後面再介紹。RabbitMQ通信端口爲5672。

OSSIM中咱們經過如下命令查看。
 

#netstat –na |grep 55672  tcp 0  0  127.0.0.1:52667     127.0.0.1:5672   ESTABLISHED

RabbitMQ環境變量的配置文件位於/etc/rabbitmq/rabbitmq-env.conf，使用時須要查詢Rabbitmq狀態命令，方法以下:
 

#rabbitmq-server alienvault     \\這裏的alienvault表明Ossim Server的主機名稱

此時，能顯示rabbitmq的端口、節點名稱和主目錄（/var/lib/rabbitmq）。

永遠不要用kill命令直接中止RabbitMQ服務器，而應該採用rabbitmqctl命令（這樣能夠將數據同步保存到磁盤，而後關閉服務）：
 

＃rabbitmqctl stop

3 選擇Key/Value存儲

早期OSSIM版本中依然是採用Mysql+memcache的架構存儲數據，因爲存在性能和一致性問題，在OSSIM4.4後續版本中引入Redis做爲隊列處理服務器，有讀者會問爲何選用Key/Value存儲？從SIEM收集業務角度出發，不管日誌仍是安全事件都屬於非結構化數據，在日誌關聯分析時，非結構化的數據量會大大超過結構化數據，這些數據之間存在關聯，若是將這些數據直接存入數據庫，那麼對數據庫訪問頻率將增長，因爲單個錶行數的猛增，對錶的訪問行數成比例增長，在多個表之間的數據調用將會產生大量的計算，足以將任何一個數據分析系統壓垮。

在分析Ossim系統各集成開源工具中發現系統沒有進行持久化，若是RabbitMQ服務器重啓會致使消息丟失，因此採用Redis Server來解決這些問題，Redis是一個Key/Value的NoSQL數據庫，Redis做爲緩存服務器，數據存儲在內存，因此速度比MySQL要快得多，尤爲在OSSIM的Web UI中不少的排行榜應用、取出TOP 10的操做、包括各類儀表盤、計算器應用、SIEM控制檯的Uniq操做、獲取某段時間全部數據的列表、取最新的TOP N操做，包括在分佈式日誌收集系統中消息隊列的處理，這些都要用到Redis服務。
 

 

 更多有關OSSIM內容，請參考《開源安全運維平臺-OSSIM最佳實踐》一書。注：以上爲樣章內容，最終效果以書中文字爲準。