OSSIM中分布式訊息佇列應用

ossim中分布式訊息佇列應用

1. 訊息佇列處理

企業日誌數量正在以指數級形式高速增長，日誌資料的具有海量、多樣、異構等特點，基於傳統的單一節點混合式安裝的ossim平台（指ossim 4.4及以下系統），無法滿足海量日誌分析要求。在ossim 4.4以後的系統中增加了中介軟體rabbitmq，可通過rabbitmq將系統中各元件解除耦合，避免了系統中執行模組的影響（例如mysql的寫操作等），這樣設計可實現分布式日誌分析平台的要求。

ossim中使用rabbitmq後，可以利用訊息佇列耦合了認證模組，也就是通過訊息佇列（message queuing）使用訊息將ossim中各種複雜應用程式連線起來。好比電腦主機板上的匯流排那樣。ossim中的訊息**伺服器採用erlang語言編寫**，提供了開源訊息佇列方案，你完全不必自己學習erlang語言，架構訊息佇列伺服器，這些負責過程ossim都完美解決。

下面看個例項，在網路出現故障前或故障過程中，各種裝置和伺服器會傳送大量日誌到日誌伺服器，在原先的設計中，這樣的日誌會直接寫入資料庫或者/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中分布式訊息佇列應用

分布式訊息佇列

分布式訊息佇列

相關推薦