?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最佳實踐》一書。

?注：以上為樣章內容，最終效果以書中文字為準。

本文出自 “李晨光原創技術博客” 博客，請務必保留此出處http://chenguang.blog.51cto.com/350944/1750918

總結

以上是生活随笔為你收集整理的OSSIM中分布式消息队列应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。