趙一寧，肖海力

中國科學院 計算機網(wǎng)絡信息中心，北京 100190

1 引言

網(wǎng)格環(huán)境通過整合、管理和調(diào)度分布式的異構(gòu)計算資源，使其形成一個虛擬的計算集群，實現(xiàn)提高高性能計算資源利用效率、提高用戶服務可靠性的目標。國家高性能計算環(huán)境是由中國科技部長期資助建設的中國國家級網(wǎng)格計算環(huán)境[1-2]，目前已經(jīng)接入全國范圍內(nèi)的17個結(jié)點的計算集群，其中包括目前計算能力排名世界第一和第二的神威太湖之光和天河二號，聚合計算資源總量超過185 PFlops，總存儲量60 PB。國家高性能計算環(huán)境使用中國科學院計算機網(wǎng)絡信息中心自主研發(fā)的網(wǎng)格中間件SCE[3]為用戶提供便捷的高性能計算服務。

在國家高性能計算環(huán)境中，各種程序和系統(tǒng)通常都會以日志的形式記錄運行中發(fā)生的各種事件。這些數(shù)據(jù)數(shù)量龐大，而且其中含有許多有助于維護系統(tǒng)安全和穩(wěn)定運行的重要事件記錄。通過監(jiān)控、分析、展示這些事件，可以對環(huán)境形成有效支撐。在過往的研發(fā)工作中，設計了網(wǎng)格環(huán)境日志分析框架LARGE（log analysing framework in grid environment）[4]，通過分析日志來發(fā)現(xiàn)隱藏在環(huán)境日志中的隱含信息。

然而由于環(huán)境設備遍布于各地的計算集群中，記錄事件的各類日志難以直接被獲取。同時由于系統(tǒng)程序記錄事件的方式各自不同，日志的格式也變化多樣，系統(tǒng)維護人員幾乎不可能快速準確地理解其中所表達的內(nèi)容。

針對這種情況，設計了國家高性能計算環(huán)境事件流處理與分發(fā)系統(tǒng)，專門用于收集環(huán)境中各種系統(tǒng)程序的日志數(shù)據(jù)。環(huán)境事件流處理與分發(fā)系統(tǒng)以Apache Kafka與Logstash程序組成消息的收集與分發(fā)平臺，通過實現(xiàn)事件工廠來對收集到的環(huán)境事件進行分類、解析、篩選、處理和封裝。事件工廠由采集模塊、分揀模塊、解碼模塊、過濾模塊、處理模塊和封裝模塊六部分組成，通過一系列加工流程，將原本內(nèi)容形式各異的事件日志轉(zhuǎn)化為統(tǒng)一格式的標準事件，并提供給包括日志分析框架和環(huán)境展示平臺在內(nèi)的各種對事件有需求的應用。將環(huán)境事件流處理與分發(fā)系統(tǒng)部署到了環(huán)境服務器中并進行了實際運行測試，結(jié)果表明該系統(tǒng)的事件處理和轉(zhuǎn)發(fā)的延時較低，完全可以滿足環(huán)境應用對于事件實時響應方面的需求。

本文首先具體介紹國家高性能計算環(huán)境對于事件流處理與分發(fā)系統(tǒng)的需求，然后在第3章介紹事件流系統(tǒng)的系統(tǒng)結(jié)構(gòu)和主要組成部分。第4章將闡述關于事件工廠的設計。第5章將給出關于事件流系統(tǒng)的實際運行測試結(jié)果。第6章是日志傳輸與分析的相關工作介紹。第7章將對本文進行總結(jié)，并且對未來的工作作出展望。

2 背景與需求介紹

國家高性能計算環(huán)境[1]是由中國眾多國家級計算中心和高校的計算集群聚合而成的大型高性能計算環(huán)境，其中中國科學院計算機網(wǎng)絡信息中心是環(huán)境的北方主結(jié)點，也是其運行管理中心。國家高性能計算環(huán)境使用中心自主研發(fā)的SCE中間件[3]作為資源調(diào)度核心，將來自多個集群的異構(gòu)資源整合起來并通過統(tǒng)一的接口提供給環(huán)境用戶，實現(xiàn)了輕量化、穩(wěn)定、可靠、低維護成本等目標。通過SCE中間件，國家高性能計算環(huán)境聚合計算能力超過185 PFlops，為國內(nèi)眾多高校和機構(gòu)的研究人員提供了優(yōu)質(zhì)計算資源，應用成果遍及量子化學、分子模擬、高能物理、生物科學、流體力學、材料科學、大氣與海洋學、天文學等眾多研究領域。

出于維護環(huán)境正常穩(wěn)定運行的目的，系統(tǒng)管理人員需要監(jiān)控環(huán)境狀態(tài)和獲取環(huán)境內(nèi)部所發(fā)生的事件信息，以確保及時迅速地對環(huán)境產(chǎn)生的問題進行預防和處理。事件信息通常以日志的形式記錄在各程序指定位置，方便管理人員對過往系統(tǒng)事件歷史進行查閱。但由于國家高性能計算環(huán)境是一種聚合而成的復雜環(huán)境，其中包含了多種多樣的程序和系統(tǒng)，因此各類事件也是復雜多變的，其事件表述格式、存儲位置、內(nèi)涵信息也都各不相同。例如，對于計算集群來說，所能產(chǎn)生的事件可能主要包括資源調(diào)度、計算任務的運行、硬件的工作狀態(tài)等信息；而對環(huán)境層面的SCE中間件來說，所產(chǎn)生的事件可能更多的是關于用戶登錄認證、命令和請求的獲取和交互、中間件與計算集群的網(wǎng)絡交互等內(nèi)容。

盡管不同類型維護人員對于這些信息的關注重點不同，但都需要一個關于信息的傳輸、篩選和提示功能。如果對于每一種類型的信息都各自建立一套處理系統(tǒng)，則所耗費的工作量巨大而且重復性高成本高，因此最好的解決辦法就是建立一個統(tǒng)一的環(huán)境事件系統(tǒng)，對環(huán)境各處產(chǎn)生的多種類型事件進行采集和集中處理，然后再根據(jù)需求將這些信息分門別類地發(fā)送到相關人員和應用處。

因此設計了國家高性能計算環(huán)境事件流處理與分發(fā)系統(tǒng)。該系統(tǒng)將基于數(shù)據(jù)分發(fā)服務技術（data distribution service）[5]，在環(huán)境事件產(chǎn)生源進行采集傳輸，根據(jù)事件內(nèi)容和系統(tǒng)關注重點進行篩選和整合重構(gòu)，并整理成為統(tǒng)一的格式，再分類發(fā)送到系統(tǒng)接口處。其他應用可以以訂閱事件類型的方式接收特定類型的事件，在獲取關注類型的同時避免接收不需要的信息。最終通過該系統(tǒng)實現(xiàn)事件處理即時化、內(nèi)容分類具體化、服務接口統(tǒng)一化、消息分發(fā)定制化。

3 系統(tǒng)結(jié)構(gòu)

環(huán)境事件流處理與分發(fā)系統(tǒng)作為國家高性能計算環(huán)境中對于事件的專用處理系統(tǒng)，其基本功能即消息數(shù)據(jù)的傳輸、存儲與分發(fā)功能。采用Apache Kafka作為系統(tǒng)的基本數(shù)據(jù)分發(fā)平臺，在此之上建立事件工廠模塊，針對環(huán)境中幾種主要的事件內(nèi)容格式進行解析、篩選、處理分析和格式轉(zhuǎn)換。此外使用Logstash作為系統(tǒng)的數(shù)據(jù)采集工具。圖1為國家高性能計算環(huán)境事件流處理與分發(fā)系統(tǒng)的基本架構(gòu)圖。

Fig.1 Structure of event stream processing and distributing system圖1 環(huán)境事件流處理與分發(fā)系統(tǒng)結(jié)構(gòu)圖

Apache Kafka是由Apache軟件基金會開發(fā)的一個開源消息系統(tǒng)項目[6]，目標是提供一個統(tǒng)一、高通量、低延遲的消息分發(fā)平臺。Kafka基于Apache Zoo‐keeper實現(xiàn)多服務器間提供一致性服務，每個Kafka服務器被稱為代理（Broker）。Kafka通過設置主題（Topic）實現(xiàn)消息分類，來自消息生產(chǎn)者（Producer）的消息被發(fā)送到指定主題中，存儲于Kafka服務器中，消息消費者（Consumer）則通過訂閱所需要的主題來接收這些類型的消息。在環(huán)境事件流處理與分發(fā)系統(tǒng)中，Kafka將同時承擔兩個任務，一是將采集到的數(shù)據(jù)按照其數(shù)據(jù)源類型發(fā)送到事件工廠的分揀模塊等待處理，二是將事件工廠輸出的統(tǒng)一格式的事件分類存儲并發(fā)送到訂閱相關事件類型的應用處。

Logstash是Elastic公司開發(fā)的一款開源數(shù)據(jù)處理程序[7]，主要用于數(shù)據(jù)采集和傳輸，同時具備基本的數(shù)據(jù)標記和格式處理功能，通常用于日志收集工作。環(huán)境事件流流出與分發(fā)系統(tǒng)將采用Logstash將數(shù)據(jù)從源設備采集并添加格式類型標簽，并經(jīng)由Kafka轉(zhuǎn)送到事件工廠。從Kafka的角度，Logstash是消息生產(chǎn)者，訂閱事件的應用是其消息消費者，而事件工廠既是消費者也是生產(chǎn)者，它從Kafka接收原始數(shù)據(jù)并加工成事件再發(fā)送到Kafka處等待各個應用獲取相關內(nèi)容。

在環(huán)境各組件發(fā)生事件時，是由相應組件程序分別記錄自己的事件日志，其中包含了所有可能產(chǎn)生的事件類型。然而在實際應用時，相關維護人員或應用程序往往只關心某一種到幾種類型的事件。因此建立事件分類是環(huán)境事件流處理與分發(fā)系統(tǒng)所必須實現(xiàn)的環(huán)節(jié)。根據(jù)環(huán)境實際運行情況和使用需求，初步將事件劃分為以下七大類：

（1）用戶操作：表示用戶在環(huán)境客戶端執(zhí)行了一種操作或請求，包括查詢環(huán)境資源、提交作業(yè)、傳輸文件等。

（2）管理操作：該類事件為僅有管理權限的用戶才能執(zhí)行的操作的記錄，包括建立用戶組、修改用戶權限等。

（3）作業(yè)狀態(tài)：這類事件表示用戶作業(yè)發(fā)生了狀態(tài)變更，例如作業(yè)準備、作業(yè)運行、作業(yè)完成，以及提交產(chǎn)生錯誤、作業(yè)運行失敗、作業(yè)被終止等異常事件，相關應用可以通過事件消息中記錄的作業(yè)號來追溯相應作業(yè)。

（4）應用狀態(tài)：主要表示集群中的應用程序的變更情況，主要包括安裝、升級或版本變更、卸載等。

（5）集群狀態(tài)：對于計算集群的當前狀態(tài)的報告，可能是一種服務器與目標集群間的周期性通訊的事件，記錄了集群的運行狀態(tài)、當前作業(yè)數(shù)等相關參數(shù)。

（6）警報事件：這種類型的事件代表環(huán)境中產(chǎn)生了需要注意或及時處理的問題，例如密碼攻擊、磁盤已滿、內(nèi)存溢出、CPU過熱、程序運行出現(xiàn)段錯誤等等，對實時性有一定要求。

（7）新日志模式：在進行事件處理時，系統(tǒng)日志將根據(jù)已經(jīng)定義的日志模式庫中的記錄進行格式匹配，而日志模式則是對于過往日志的類別總結(jié)[8]，然而當系統(tǒng)日志出現(xiàn)了不存在于過往日志的新模式記錄時，系統(tǒng)無法判斷是否需要針對該模式制定新的環(huán)境警報規(guī)則和策略，因此需要將其內(nèi)容作為一種事件發(fā)布給制定警報規(guī)則的維護人員處。

相關應用程序在訂閱事件時，將以上述七種類型為對象。對于每種類型事件還可以具體劃分子類的情況，各應用需要自行定義相應的處理辦法。在未來實際運行過程中如果出現(xiàn)新的需求，也可以在上述七種事件類型以外增添更多的基礎事件類型對象。

4 事件工廠工作流程

在國家高性能計算環(huán)境中，環(huán)境中間件的組件和集群程序以及操作系統(tǒng)都可能成為環(huán)境事件的產(chǎn)生源，這些程序記錄事件的方式各不相同，也就難以使用一種通用的方法獲取其中信息。以Linux操作系統(tǒng)日志和SCE中間件日志為例，Linux系統(tǒng)日志的格式通常為英文句式，屬于人類可讀內(nèi)容，然而對于機器來說其中的關鍵內(nèi)容較少，僅存在于語句的特定位置；而SCE中間件日志的表現(xiàn)形式為許多字段，每個字段僅包含必要信息內(nèi)容，特點是信息量大，便于機器提取信息，但人類不可讀，僅具備專家知識的人員才能理解。對于這兩種不同的事件形式，相關應用不可能使用同一種解析方法獲取其中的信息。

出于此種需求，在環(huán)境事件流處理與分發(fā)系統(tǒng)中增加了事件工廠模塊。事件工廠主要用于接收各種類型格式的事件，并使用各自的解析方法對其中主要內(nèi)容進行提取，然后篩選可能含有重要內(nèi)容的事件進行統(tǒng)一處理，最終將這些事件信息封裝成為符合事件工廠統(tǒng)一接口的格式發(fā)布成為各種事件類型。當相關應用接收到訂閱的事件時，只需要按照事件工廠的統(tǒng)一接口進行解析就可以獲取其中的關鍵信息。

圖2為事件工廠的內(nèi)部模塊以及工作流程圖。如圖所示，事件工廠主要包含六個模塊，對于每一個需要分發(fā)的事件消息，都需要經(jīng)過這六個模塊。對于經(jīng)由Kafka而來的原始數(shù)據(jù)，首先由采集模塊將其獲取到事件工廠處等待處理。采集模塊通過實現(xiàn)Kafka的消費者客戶端來達到收集原始數(shù)據(jù)的目的。

隨后數(shù)據(jù)來到分揀模塊，由于在負責源設備采集的Logstash程序已經(jīng)為數(shù)據(jù)打上了數(shù)據(jù)源的標簽，分揀模塊將根據(jù)這些標簽決定將數(shù)據(jù)發(fā)往何處。分揀模塊還需要負責分行數(shù)據(jù)整合的問題：在記錄日志時，部分程序會出現(xiàn)把一條消息分成多行日志進行記錄的情況，而Logstash是以行為單位進行數(shù)據(jù)采集的。分揀模塊就需要實現(xiàn)處理此類情況的方法，將分行的數(shù)據(jù)重新合并為一條事件記錄，再發(fā)送到目標車間。

Fig.2 Workflow of modules in event factory圖2 事件工廠模塊工作流程圖

根據(jù)原始日志格式的不同，事件工廠內(nèi)存在多個工作車間，每個車間都包含兩個模塊的步驟，分別為解碼模塊和過濾模塊。事件流系統(tǒng)需要收集多少種格式的日志，事件工廠就需要相應數(shù)量的車間用于處理相應日志格式。解碼模塊的主要工作就是根據(jù)車間對應的日志格式進行解碼，將原始的一行數(shù)據(jù)分解為若干個字段，每個字段是一個（key，value）的值對，key代表字段標識，同時也表示了字段含義，value是字段值，也即內(nèi)容信息。例如一個幾乎必需存在的標識就是事件時間，基本上所有種類的日志記錄都需要記錄發(fā)生時間，但記錄格式可能不同。而該值將在解碼模塊被分解出來并形成時間戳的統(tǒng)一格式。

過濾模塊將根據(jù)需求對經(jīng)由解碼模塊處理過的事件進行篩選過濾，因此部分不被相關人員和應用所關注的事件將在此處被丟棄。以Linux系統(tǒng)日志為例，系統(tǒng)日志車間的過濾模塊與兩個模式庫進行交互，分別為日志模式庫Pl和警報模式庫Pa。日志模式庫包含過往系統(tǒng)日志記錄的所有日志模式，警報模式庫則僅包含部分需要關注的日志模式（為日志模式庫的子集），并且注明了關注原因。當系統(tǒng)日志事件e來到過濾模塊時：

（1）判斷e是否匹配于警報模式庫Pa中的任意一種模式：

（1.1）若e與Pa成功匹配，則為其添加關注原因的字段并將其發(fā)往處理模塊；

（1.2）若e沒有匹配到警報模式，則進入步驟（2）。

（2）將e與日志模式庫Pl中的日志模式進行匹配：

（2.1）若e仍未成功匹配Pl，則判斷e為新日志模式，將被添加相關字段并發(fā)往處理模塊；

（2.2）若e與Pl匹配成功，則e為環(huán)境普通事件，事件流系統(tǒng)將不再對其進行任何處理（即丟棄事件）。

通過了過濾模塊的事件將來到處理模塊，該模塊用于多條事件的綜合處理。處理模塊存在的原因是：并非所有事件都獨立成為一個需要關注的事件，例如用戶密碼輸入錯誤的記錄，當其單獨存在時可能僅僅表明用戶的偶然輸入錯誤，但如果短時間內(nèi)同一賬戶連續(xù)多次輸錯密碼，則很可能代表一次需要警報的密碼攻擊。處理模塊就是用來處理此類由多條事件組合而成的綜合事件，它需要建立若干隊列用于存儲可能組成不同綜合事件的單條事件記錄，同時還需要周期性地執(zhí)行清理工作，刪除那些已經(jīng)經(jīng)過較長時間但仍未組成綜合事件的單條記錄。對于本身即構(gòu)成需要發(fā)布的事件的單條記錄和已經(jīng)成型的綜合事件，處理模塊會將其發(fā)往封裝模塊。

封裝模塊會對事件進行最終處理，將被分為多個字段的事件重新打包成為一個完整的字符串，該字符串需符合環(huán)境事件流處理與分發(fā)系統(tǒng)所定義的事件工廠統(tǒng)一接口的格式。該接口為JSON格式的信息內(nèi)容，分為兩到三個層級：第一層級為事件公共報頭，包含了事件發(fā)生時間和事件類型；第二層級為事件主體，其中的字段標識根據(jù)第一層級的事件類型而定。部分事件還有第三層級內(nèi)容，通常為事件主體的關鍵內(nèi)容的參數(shù)或詳細屬性值。下面為一個經(jīng)過封裝的事件內(nèi)容格式的樣例：

封裝模塊還實現(xiàn)了Kafka的生產(chǎn)者客戶端功能，經(jīng)過封裝的事件將根據(jù)其類型發(fā)布到Kafka的相應主題之中。至此為一個事件經(jīng)歷的完整的事件工廠工作流程。

當一個訂閱環(huán)境事件的應用接收到事件時，首先讀取第一層級中的事件類型（type）字段，根據(jù)該字段的內(nèi)容判斷其第二層級存在哪些字段。以上面的事件內(nèi)容為例，應用程序發(fā)現(xiàn)其type字段為用戶操作（USER_OP）時，根據(jù)事件接口格式它就可以知道在該事件第二層級中會包含用戶名、用戶訪問地址和該操作類型（op字段，此處該值代表“查詢計算資源”）等字段，結(jié)合第一層級的時間字段，該應用即可得知用戶usr1在某一時間執(zhí)行了一次查詢資源操作。若該應用需要進一步分析這次操作，則根據(jù)操作類型可以獲知本次操作包含哪些操作參數(shù)字段，例如用戶請求的CPU核數(shù)（8核）、目標計算應用（app4）等內(nèi)容。通過累積該類型事件的記錄，環(huán)境管理人員即可統(tǒng)計分析得出某段時間內(nèi)用戶對于資源的需求情況。

5 系統(tǒng)工作效果

國家高性能計算環(huán)境事件流處理與分發(fā)系統(tǒng)的主要目的是對環(huán)境中的事件數(shù)據(jù)進行采集和傳輸，同時進行一些基本的格式和內(nèi)容處理。對于這種類型的系統(tǒng)，數(shù)據(jù)發(fā)送延時是一項關鍵指標。對于集群的各種事件消息，希望能盡快地發(fā)送到對此有需求的各種環(huán)境應用處。

因此初步實現(xiàn)了環(huán)境事件流處理與分發(fā)系統(tǒng)的各個模塊基本功能，并將其部署到了國家高性能計算環(huán)境中進行效果測試。設置了一臺虛擬機的日志服務器專門用于收集來自環(huán)境各部分的日志，并將事件流系統(tǒng)安裝在該服務器上，對收集來的日志進行轉(zhuǎn)換處理和分發(fā)，同時設計實現(xiàn)了一個簡單的測試應用來訂閱事件流系統(tǒng)所發(fā)布的所有事件，并計算接收到事件的時間與事件流系統(tǒng)采集到該事件時間之間的延時。

本實驗主要設備日志服務器虛擬機的CPU為2 400 MHz的英特爾4核處理器，64位操作系統(tǒng)，內(nèi)存總量為4 GB。由于其他設備與日志服務器的系統(tǒng)時間可能存在不一致的情況，統(tǒng)一以日志服務器的系統(tǒng)時間為準。本實驗的主要目的為測試系統(tǒng)中事件工廠的事件處理速度，因此實驗的結(jié)果僅包括事件工廠對事件的處理時間以及事件經(jīng)由Apache Kafka發(fā)布到測試應用所花費的時間，而不包括網(wǎng)絡傳輸時間以及不同設備間系統(tǒng)時間不一致所產(chǎn)生的誤差。

以分鐘為單位計算了該分鐘內(nèi)產(chǎn)生事件總數(shù)和事件平均延時，事件對象為環(huán)境中的系統(tǒng)日志，總共采取了約90 min的數(shù)據(jù)結(jié)果。圖3為每分鐘內(nèi)事件平均延時，可以看到，環(huán)境事件流處理與分發(fā)系統(tǒng)對于系統(tǒng)日志的處理事件和發(fā)布時間均值大都在5 ms至10 ms之間波動，部分時刻會達到14 ms，但總體上不超過20 ms。在不考慮網(wǎng)絡等其他不在可控范圍之內(nèi)的延遲的情況下，環(huán)境事件流系統(tǒng)對于單個事件的處理速度是比較快的，完全可以滿足環(huán)境應用對于事件的時效性需求，并起到實時響應和處理的效果。

針對圖3中出現(xiàn)的事件處理延時會不定期向上波動的問題，也觀察了實驗期間每分鐘事件產(chǎn)生數(shù)量與該分鐘內(nèi)平均事件處理延時之間的關系。圖4展示了實驗期間系統(tǒng)日志事件的每分鐘內(nèi)事件數(shù)量。圖5為每分鐘內(nèi)的事件數(shù)量和事件延時的對比結(jié)果?？梢钥吹皆趯嶒炂陂g，多數(shù)時候環(huán)境系統(tǒng)日志平均每分鐘產(chǎn)生的事件數(shù)量在約75到140條，少數(shù)時候會增加到150條，最多時接近250條。雖然結(jié)果有一些偏差，但總體上有一個較為清晰的線性趨勢，即當單位時間內(nèi)所產(chǎn)生的事件數(shù)量增加時，事件流系統(tǒng)對于單條數(shù)據(jù)的平均延時會相應增加。然而由于事件處理延時在整體上表現(xiàn)在一個相當?shù)偷姆秶春撩爰壍臉藴?，因此預測在環(huán)境事件流量繼續(xù)增加時，事件流系統(tǒng)對于環(huán)境事件的處理延時可能會提升一個數(shù)量級，但仍然處于一個較為迅速的范圍內(nèi)，可以滿足環(huán)境應用對事件的時效性需求。此外環(huán)境事件流量突然增大這種情況屬于偶發(fā)情況，在絕大多數(shù)時間內(nèi)，環(huán)境會處于一種正常平穩(wěn)運行的狀態(tài)，對于事件處理的速度也會維持在高標準。

Fig.3 Average delay for event process in each minute圖3 每分鐘內(nèi)事件處理過程平均延時

Fig.4 Event throughput in each minute圖4 每分鐘內(nèi)事件數(shù)量

Fig.5 Average delay against event throughput圖5 事件流量與事件平均延時的關系

6 相關工作

在過往的研究中設計實現(xiàn)了網(wǎng)格環(huán)境日志分析框架LARGE[4]。LARGE是部署在中科院超級計算環(huán)境中的日志分析框架，其主要工作內(nèi)容如下：

（1）采集環(huán)境中的日志信息實現(xiàn)集中存儲；

（2）對日志進行解碼重構(gòu)和統(tǒng)計分析，得到初步結(jié)果；

（3）通過人工整理形成對環(huán)境有幫助的反饋。

為了實現(xiàn)對于日志的監(jiān)控規(guī)則的自定義，提出了日志模式提煉算法[8]對過往日志進行總結(jié)并獲得一個數(shù)量較少的日志模式集合，并以日志模式為單位進行定義日志規(guī)則的工作。

本文介紹的環(huán)境事件流處理與分發(fā)系統(tǒng)是對LARGE系統(tǒng)研究開發(fā)工作的延續(xù)。在研究過程中出現(xiàn)了更多需求和相關使用場景，因此針對環(huán)境事件采集的環(huán)節(jié)進行了更加詳細的流程設計和定義擴展，使之適用于更多的環(huán)境應用，從而形成了事件流系統(tǒng)。環(huán)境事件流處理與分發(fā)系統(tǒng)的主要工作內(nèi)容如下：

（1）采集環(huán)境中的日志原始數(shù)據(jù)；

（2）進行初步解碼過濾和重組，封裝成標準格式；

（3）對事件分類，發(fā)送到相關應用處。

相對LARGE系統(tǒng)，事件流系統(tǒng)只進行基礎的日志過濾和格式處理，而仍然保留原始信息的完整內(nèi)涵，這些信息將由包括LARGE處理分析模塊在內(nèi)的其他環(huán)境應用進行更具體更有針對性的解讀和使用。在事件流系統(tǒng)中，日志模式仍然起到了重要作用，事件流系統(tǒng)通過日志模式的比對來實現(xiàn)日志事件的過濾工作。

目前對于分布式系統(tǒng)中關于監(jiān)控和日志處理的研究工作主要集中在對系統(tǒng)狀態(tài)的監(jiān)控和對日志數(shù)據(jù)的傳輸方面。Ganglia[9]是UC Berkeley主導開發(fā)的一個開源項目，目標是實現(xiàn)對系統(tǒng)的CPU、內(nèi)存、磁盤使用率、網(wǎng)絡等狀態(tài)的監(jiān)控。Nagios[10]也是一種系統(tǒng)監(jiān)控工具，可以使用插件實現(xiàn)通過網(wǎng)頁展示系統(tǒng)狀態(tài)的功能。在中科院超級計算環(huán)境中已經(jīng)部署配置了基于Nagios的監(jiān)控系統(tǒng)[11]，它與LARGE共同承擔了對環(huán)境的監(jiān)控和分析的工作。

Scribe（https：//github.com/facebookarchive/scribe/）是Facebook的日志收集系統(tǒng)，可以將日志從各個源設備傳輸?shù)揭慌_集中存儲設備上。相似的系統(tǒng)還有由Cloudera開發(fā)的Flume[12]，它將傳輸流程分為source、channel和sink三部分，每部分都有多種選擇。這些數(shù)據(jù)傳輸工具都可以被用于實現(xiàn)LARGE的日志收集模塊。Chukwa（http：//chukwa.apache.org/）是 Hadoop項目中開源的分布式系統(tǒng)數(shù)據(jù)收集和分析工具，包含了數(shù)據(jù)收集、重組、分析和展示的完整流程。由于系統(tǒng)情況的差別，Chukwa不能直接應用于超級計算環(huán)境，但仍可以作為一個有益的參考。

在環(huán)境事件流處理與分發(fā)系統(tǒng)中使用了Logstash作為事件傳輸平臺的一部分。Logstash是Elastic公司開發(fā)的數(shù)據(jù)采集軟件，它與Elastic公司開發(fā)的其他軟件具備更好的結(jié)合度。近年來對于Elastic公司開發(fā)的ELK組合（ElasticSearch、Logstash、Kibana）的研究和使用呈現(xiàn)顯著增長趨勢[13-15]，ELK可以作為一個實時的數(shù)據(jù)分析框架，并且對日志流處理有一定優(yōu)勢。不過ELK框架提供的分析功能相對簡單，需要設計其他輔助分析程序來滿足特定系統(tǒng)或環(huán)境對分析的需求。

Apache Eagle是Apache項目推出的一款開源的分布式系統(tǒng)實時安全監(jiān)控分析方案（http：//eagle.apache.org/），主要針對 Apache Hadoop和 Apache Spark等大數(shù)據(jù)平臺。Eagle實現(xiàn)了關于系統(tǒng)行為、yarn應用、jmx數(shù)據(jù)、系統(tǒng)服務日志等數(shù)據(jù)的分析功能，并且提供了關于安全、性能等方面的警報引擎。Eagle的工作流程主要分為三步：首先整合來自目標大數(shù)據(jù)平臺的相關日志和數(shù)據(jù)；然后將實時的數(shù)據(jù)流進行標準化等處理并在警報引擎中進行評估；最終生成警報、趨勢報告等輸出結(jié)果?？梢钥吹紼agle與本文介紹的環(huán)境事件流處理與分發(fā)系統(tǒng)具有一定的相似性，而且Eagle系統(tǒng)中同樣使用了Kafka作為數(shù)據(jù)傳輸?shù)慕鉀Q方案。相比而言，Eagle的主要分析對象是Apache項目的各種系統(tǒng)、程序、服務和數(shù)據(jù)，并且提供了相應的警報功能，是一個綜合性的處理工具；而環(huán)境事件流系統(tǒng)的主要設計目標是解決國家高性能計算環(huán)境中的各類事件信息和相關數(shù)據(jù)的傳輸問題，并實現(xiàn)了初步的內(nèi)容解析和分類，是整個環(huán)境監(jiān)控分析的一個關鍵模塊。對于環(huán)境數(shù)據(jù)的實際使用等方面的功能則交由訂閱事件的相關應用來實現(xiàn)，包括網(wǎng)格環(huán)境日志分析框架LARGE、環(huán)境事件展示平臺等。

7 總結(jié)與展望

本文介紹了關于國家高性能計算環(huán)境事件流處理與分發(fā)系統(tǒng)的設計。事件流系統(tǒng)的主要目標是通過專用的系統(tǒng)來收集國家高性能計算環(huán)境中產(chǎn)生的各種事件信息，并按照事件內(nèi)容分類發(fā)送給對事件有需求的環(huán)境應用處。采用Apache Kafka與Logstash的組合作為系統(tǒng)基本的消息收集和分發(fā)平臺，并著重設計實現(xiàn)了事件工廠用于對各種事件進行梳理和封裝。事件工廠包含了六種模塊，通過對事件內(nèi)容的解析和過濾選取含有重要信息的事件，并通過綜合處理整合多條事件記錄形成綜合事件，最終封裝成符合事件工廠統(tǒng)一格式的事件消息，再通過分發(fā)平臺按照其事件類型分發(fā)給訂閱相關類型的環(huán)境應用。將環(huán)境事件流處理與分發(fā)系統(tǒng)部署到環(huán)境服務器中并進行了運行測試，結(jié)果證明系統(tǒng)在事件處理傳輸方面具有較低的延時，可以滿足環(huán)境相關應用對事件獲取的需求。

接下來將進一步擴展事件工廠對于環(huán)境各種事件格式的解析處理功能，以應對更多的環(huán)境事件類型。還將研究多樣的針對事件的環(huán)境應用，包括多維度日志分析和監(jiān)控、環(huán)境用戶行為特征分析、環(huán)境事件流可視化展示界面等，通過多樣的方式最大化利用事件流系統(tǒng)，為國家高性能計算環(huán)境的穩(wěn)定運行和維護工作提供更多更好的支持。