應用軟件運行日志的收集與服務處理框架

張 驍，應 時 ，張 韜

1.武漢大學 軟件工程國家重點實驗室，武漢 430072

2.武漢大學 計算機學院，武漢 430072

3.中國移動通信集團 湖北有限公司，武漢 430023

在信息系統(tǒng)應用中，每次操作都會留下痕跡，這就是日志，每個日志文件由日志記錄組成，每條日志記錄描述了一次單獨發(fā)生的事件[1]。在一個完整的信息系統(tǒng)里面，日志系統(tǒng)是一個非常重要的功能組成部分。它可以記錄下系統(tǒng)所產(chǎn)生的所有行為，并按照某種規(guī)范表達出來。日志為服務器、工作站、防火墻和應用軟件等IT資源相關(guān)活動記錄必要的、有價值的信息，這些信息的記錄對系統(tǒng)監(jiān)控、查詢、安全審計和診斷故障都是十分重要的[2]。

現(xiàn)有的大規(guī)模軟件大都是多人開發(fā)，或者采用多種來源的軟件，集成了大量開源社區(qū)的代碼，軟件內(nèi)部的代碼風格存在許多不一致，這種應用程序運行日志由于組織龐大，架構(gòu)復雜，日志數(shù)據(jù)量巨大且比較分散，存在日志數(shù)據(jù)格式多樣，數(shù)據(jù)存儲和檢索困難、日志數(shù)據(jù)讀取效率低等問題。導致大量日志數(shù)據(jù)信息無法被充分地挖掘利用，用戶很難快速從日志中得到有效的信息，難以達到提高故障診斷效率的目的[3]。

目前一些開發(fā)團體在他們的日志管理系統(tǒng)加入了一些日志處理方法，但都存在很多問題，如：日志數(shù)據(jù)的存儲混亂；面向用戶的服務涉及得很少，用戶很難根據(jù)需求定制日志數(shù)據(jù)。目前大多數(shù)日志數(shù)據(jù)處理工具面對海量化的日志數(shù)據(jù)處理往往達不到用戶的需求，因此，如何快速有效地對日志進行處理，并將有用的日志信息進行返回是目前日志服務研究必須考慮的一個問題[4-5]。

本文針對以上問題，提出了一種基于Spark的應用軟件運行日志的收集與服務處理框架，該框架利用分布式收集策略對日志數(shù)據(jù)收集，定義了一種多層次數(shù)據(jù)存儲結(jié)構(gòu)對日志數(shù)據(jù)進行存儲，并向用戶提供日志數(shù)據(jù)查詢服務。其特色主要體現(xiàn)在多層次的日志數(shù)據(jù)收集和存儲兩方面。通過分布式收集策略解決了日志數(shù)據(jù)收集緩慢的問題，并通過本文提出的多層次的日志數(shù)據(jù)存儲解決了由于日志數(shù)據(jù)多樣化導致在日志數(shù)據(jù)存儲上消耗大量資源的問題。

1 相關(guān)工作

隨著應用軟件的運行日志不斷增多，越來越多的研究人員開始關(guān)注日志收集和服務處理這方面的研究工作，同時也出現(xiàn)了大量針對這方面研究的軟件與系統(tǒng)，Scribe是Facebook開源的日志收集系統(tǒng)，在Facebook內(nèi)部已經(jīng)得到大量的應用。它能夠從各種日志源上收集日志。logstash是一個應用程序日志、事件的傳輸、處理、管理和搜索的平臺，可以用它來統(tǒng)一對應用程序日志進行收集管理，提供 Web接口用于查詢和統(tǒng)計。Flume[6]是Cloudera提供的一個高可用的、高可靠的、分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)。但是這些軟件大多數(shù)只傾向于收集日志，收集后的日志并沒有后續(xù)的處理，難以達到用戶對日志數(shù)據(jù)精確化的需求。

目前許多研究學者也對日志收集和服務處理這塊有很多研究，廖湘科等人[3]從日志特征分析、基于日志的故障診斷、日志的增強三方面綜述了日志研究的現(xiàn)狀。通過對軟件缺陷特征的分析，對幾種常用的大規(guī)模開源軟件的日志進行調(diào)研，發(fā)現(xiàn)了一些日志相關(guān)的特征和規(guī)律，以及現(xiàn)有工具難以解決的問題。周江[7]設計并實現(xiàn)了一個面向大數(shù)據(jù)分析、專為大規(guī)模集群應用的分布式文件系統(tǒng)Clover。實現(xiàn)了對海量數(shù)據(jù)的存儲，解決了傳統(tǒng)的分布式文件系統(tǒng)在擴展性、可靠性和數(shù)據(jù)訪問性能等方面難以滿足新形勢下的需求。李玉榮[6]在分析大型分布式系統(tǒng)對日志服務需求的基礎上，設計并實現(xiàn)了一種分布式環(huán)境下的日志服務，采用這種分布式日志服務有效地簡化了分布式應用系統(tǒng)的開發(fā)、調(diào)試和維護,但是文中沒有考慮到日志數(shù)據(jù)實際上是一種大數(shù)據(jù)，并沒有使用適合大數(shù)據(jù)存儲的數(shù)據(jù)結(jié)構(gòu)。付博[1]首先介紹了Web查詢?nèi)罩镜某Ｓ眯畔⒑凸_的數(shù)據(jù)集；進而闡述了查詢?nèi)罩驹赪eb搜索、信息抽取等方面的相關(guān)研究，并對它們進行了細致的介紹和分析，但是只適合對于Web端的查詢?nèi)罩荆瑢密浖\行日志的分析研究存在不足。申利民[8]通過對面向SAAS模式的日志架構(gòu)進行相應的配置和擴展，能夠滿足SaaS軟件分別針對不同用戶記錄日志的要求，從總體上描述架構(gòu)的框架設計，但是該框架只適合針對SAAS模式下的日志研究，并不適用于普通應用軟件的運行日志研究。

2 日志數(shù)據(jù)服務層次框架

為了能夠在該框架的每個部位找到對應的日志服務，本文針對該框架設計了三層結(jié)構(gòu)，其中層次與其對應的服務如圖1所示，該框架針對圖1左邊日志數(shù)據(jù)服務的三個層次，在右邊分別提供對應的服務，包括資源層的日志收集服務、服務層的日志數(shù)據(jù)存儲服務、應用層的用戶獲取日志數(shù)據(jù)服務。下面對不同層次的不同服務進行敘述。

圖1 日志數(shù)據(jù)服務框架

（1）日志數(shù)據(jù)資源層：實現(xiàn)日志收集工作。

（2）日志數(shù)據(jù)服務層：提供日志處理與存儲服務。

（3）日志數(shù)據(jù)應用層：提供數(shù)據(jù)接口供用戶使用。

其中，日志數(shù)據(jù)資源層是為了實現(xiàn)日志數(shù)據(jù)集的收集工作，日志數(shù)據(jù)服務層相當于一個日志處理平臺，能夠根據(jù)不同的需求對日志數(shù)據(jù)進行處理；日志數(shù)據(jù)應用層主要是向用戶提供日志服務。

該框架具有以下幾個特性：

（l）高可擴展性。由于框架分為三個層級，每個層次直接相互獨立，因此能夠滿足在日志數(shù)據(jù)不斷增長的同時，通過添加服務器，擴展存儲空間等簡單手段提升該框架的處理日志數(shù)據(jù)的能力，滿足用戶需求。

（2）高并發(fā)。該框架采用了分布式收集策略實現(xiàn)對數(shù)據(jù)的收集，能夠最大限度減少收集數(shù)據(jù)的等待時間。

（3）高容錯性。通過多層次的數(shù)據(jù)存儲結(jié)構(gòu)來保證數(shù)據(jù)不會丟失，從而提高容錯能力。

2.1 日志數(shù)據(jù)資源層

資源層是整個日志數(shù)據(jù)服務框架的基礎，負責提供原始日志數(shù)據(jù)收集服務，原始日志數(shù)據(jù)是一切研究的基礎，有了原始數(shù)據(jù)下一步的研究才能繼續(xù)下去，因此如何快速獲得原始數(shù)據(jù)非常重要。原始日志數(shù)據(jù)在各類應用軟件中分布較多，日志數(shù)據(jù)存放位置也不集中，如果要直接通過日志服務將日志收集，就會導致日志傳輸過慢，系統(tǒng)負載過重，單個節(jié)點失效而導致整個日志收集系統(tǒng)的崩潰等危險，為了提高收集日志的效率，本文采用了分布式日志收集策略，作用于應用層上運行的應用軟件上，當運行應用程序時，便會記錄該應用程序的運行日志，分布式日志收集策略有以下幾點優(yōu)點：

（1）可以將分布在各處的日志數(shù)據(jù)集中起來綜合利用，這種利用對用戶而言是透明的。

（2）可以將負載由單個節(jié)點轉(zhuǎn)移到多個，從而提高效率，這對于大數(shù)據(jù)量的日志文件收集效率的提高是很明顯的。

（3）分布式技術(shù)可以避免由于單個節(jié)點失效而使整個系統(tǒng)崩潰的危險。

2.2 日志數(shù)據(jù)服務層

服務層是整個日志服務框架的核心部分，服務層通過對資源層提供的原始日志數(shù)據(jù)進行預處理后，向用戶提供精確化的日志數(shù)據(jù)。在服務層主要包含兩種服務：日志數(shù)據(jù)預處理服務與日志數(shù)據(jù)存儲服務。

2.2.1 日志數(shù)據(jù)預處理服務

日志數(shù)據(jù)預處理服務：日志數(shù)據(jù)預處理服務是整個應用層服務的核心服務，負責將原始日志數(shù)據(jù)根據(jù)需求將不必要的信息剔除，留下用戶需要的消息。本文中數(shù)據(jù)預處理，包括對原始數(shù)據(jù)做出以下三方面預處理工作：數(shù)據(jù)過濾、數(shù)據(jù)去重與日志記錄分段。首先一個原始日志數(shù)據(jù)集中會包含大量不必要的記錄，如系統(tǒng)控制臺記錄，這些對于普通用戶來說，并不是必須的，因此需要對原始日志數(shù)據(jù)進行過濾；其次是日志去重，一個原始日志數(shù)據(jù)集中會包含大量重復的記錄，需要將重復的日志記錄去除；最后是日志記錄分段，一般日志數(shù)據(jù)格式：時間-日志等級-服務名稱-發(fā)生的事件。這樣一條原始日志數(shù)據(jù)用戶無法進行閱讀，因此需要對日志記錄進行分段，不同的詞段代表不同的含義。

2.2.2 多層次的日志數(shù)據(jù)存儲服務

日志數(shù)據(jù)存儲服務：日志數(shù)據(jù)存儲服務是服務層的一個重要構(gòu)成部分，負責對原始數(shù)據(jù)以及預處理后的數(shù)據(jù)進行存儲。應用軟件的運行日志具有以下特點[9]：

（1）數(shù)據(jù)容量巨大。應用軟件運行時會產(chǎn)生海量的上下文日志信息，這些數(shù)據(jù)隱含了海量有價值的支持故障診斷的數(shù)據(jù)信息，是后續(xù)工作得以進行的前提，因此需要一個海量數(shù)據(jù)存儲系統(tǒng)支持原始日志數(shù)據(jù)的存儲。

（2）數(shù)據(jù)產(chǎn)生速度快。隨著應用服務的不斷增多，處理用戶請求也越來越多，每秒產(chǎn)生的應用軟件運行日志記錄數(shù)也越大，使得對日志數(shù)據(jù)量的精確預計變得困難，這對存儲系統(tǒng)的水平擴展能力提出了更高的要求。

（3）異構(gòu)的日志記錄結(jié)構(gòu)。原始日志記錄的格式根據(jù)運行時場景提供日志記錄信息，通常Debug日志會包含服務方法的參數(shù)信息，Error日志會包含異常堆棧信息，Info日志則含有相對簡略的信息。

以上闡述存儲的日志數(shù)據(jù)的特點，恰好符合大數(shù)據(jù)規(guī)模大、速度快、多樣性特點，表明了應用軟件運行日志數(shù)據(jù)實質(zhì)上是一種大數(shù)據(jù)。

目前的常見的數(shù)據(jù)庫類型包括關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫優(yōu)點包括：

（1）數(shù)據(jù)的結(jié)構(gòu)化。數(shù)據(jù)庫中的數(shù)據(jù)并不是雜亂無章、毫不相干的，它們具有一定的組織結(jié)構(gòu)，屬于同一集合的數(shù)據(jù)具有相似的特征。關(guān)系型數(shù)據(jù)庫的模型一般用二維表來表示，二維表結(jié)構(gòu)是非常貼近邏輯世界一個概念，關(guān)系模型相對網(wǎng)狀、層次等其他模型來說更容易理解。

（2）數(shù)據(jù)的安全性。關(guān)系型數(shù)據(jù)庫對每次數(shù)據(jù)的訪問都有中介，這種狹窄的接口有助于數(shù)據(jù)安全。

（3）數(shù)據(jù)的完整性。數(shù)據(jù)的完整性是指保證數(shù)據(jù)庫中數(shù)據(jù)的正確性。可能造成數(shù)據(jù)不正確的原因很多，關(guān)系型數(shù)據(jù)庫通過對數(shù)據(jù)性質(zhì)進行檢查而管理它們。豐富的完整性（實體完整性、參照完整性和用戶定義的完整性）大大減低了數(shù)據(jù)冗余和數(shù)據(jù)不一致的概率。

（4）數(shù)據(jù)的靈活性。關(guān)系型數(shù)據(jù)庫不是把數(shù)據(jù)簡單堆積，它在記錄數(shù)據(jù)信息的基礎上具有很多的管理功能，如輸入、輸出、查詢、編輯修改等，同時它的操作基于集合運算與謂詞演算，非常靈活。

非關(guān)系型數(shù)據(jù)庫優(yōu)點包括：

（1）不需要預定義模式：不需要事先定義數(shù)據(jù)模式，預定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當插入數(shù)據(jù)時，并不需要預先定義它們的模式，因此在大數(shù)據(jù)量的情況下，非關(guān)系型數(shù)據(jù)庫表現(xiàn)出非常高的讀寫性能。

（2）基于鍵值對，數(shù)據(jù)沒有耦合性，容易擴展；并且非關(guān)系型數(shù)據(jù)庫在不太影響性能的情況下就可以方便地實現(xiàn)高可用的架構(gòu)。

（3）存儲數(shù)據(jù)的格式：nosql的存儲格式是key，value形式、文檔形式、圖片形式等等，而關(guān)系型數(shù)據(jù)庫則只支持基礎類型。

以上介紹了兩種數(shù)據(jù)庫的優(yōu)點，但事實上這還存在不少缺點：

（1）關(guān)系型數(shù)據(jù)庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差；固定的表結(jié)構(gòu)；高并發(fā)讀寫需求；海量數(shù)據(jù)的高效率讀寫難以支持。

（2）非關(guān)系型數(shù)據(jù)缺點是不提供sql支持，學習和使用成本較高，例如用戶查詢這樣的工作成本會很高；無事務處理，附加功能和報表等支持也不好。

由以上可以看出關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫各有優(yōu)缺點，但是某種程度上兩種數(shù)據(jù)庫又可以互補。本文中如果采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫對原始日志數(shù)據(jù)進行存儲管理，將會出現(xiàn)難以支持海量數(shù)據(jù)存儲的問題，所以需要設計一種適合大數(shù)據(jù)量日志存儲的數(shù)據(jù)存儲結(jié)構(gòu)。因此利用基于海量數(shù)據(jù)的分布式非關(guān)系數(shù)據(jù)庫來對大數(shù)據(jù)日志進行存儲，但一般的基于海量數(shù)據(jù)的分布式非關(guān)系數(shù)據(jù)庫對服務層的日志數(shù)據(jù)插入刪除修改的支持比較薄弱，而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫對插入刪除的支持比較好，但是對大數(shù)據(jù)存儲這塊比較薄弱，為了解決兩者的矛盾，并將兩種數(shù)據(jù)庫的優(yōu)點體現(xiàn)出來，本文將二者相結(jié)合，將日志數(shù)據(jù)分為兩種：一種是原始日志數(shù)據(jù)，當前數(shù)據(jù)會存放到關(guān)系型數(shù)據(jù)庫集群中；另一種是預處理后的日志數(shù)據(jù)，預處理后的日志數(shù)據(jù)存放到基于海量數(shù)據(jù)的分布式非關(guān)系數(shù)據(jù)庫中，這樣對原始日志數(shù)據(jù)進行插入刪除修改可以在關(guān)系型數(shù)據(jù)庫集群中進行，對預處理后的日志數(shù)據(jù)進行查詢的工作放在基于海量數(shù)據(jù)的分布式非關(guān)系數(shù)據(jù)庫中執(zhí)行，通過這種多層次的數(shù)據(jù)庫存儲結(jié)構(gòu)，既保障了對原始日志數(shù)據(jù)的增添修改，又解決了對大數(shù)據(jù)量日志數(shù)據(jù)的存儲問題。

2.3 日志數(shù)據(jù)應用層

應用層是面向用戶的，目的是為用戶提供預處理后的日志數(shù)據(jù)，預處理后的數(shù)據(jù)會存放在服務層的數(shù)據(jù)庫中，本文通過提供多條件查詢服務接口，向用戶提供查詢服務，用戶可以根據(jù)不同的需求來查詢?nèi)罩緮?shù)據(jù)[10]。

2.4 框架中的數(shù)據(jù)流

整個日志數(shù)據(jù)框架的數(shù)據(jù)流如圖2所示。

日志框架的數(shù)據(jù)通過分布式收集策略從各個節(jié)點上收集而來，這也是數(shù)據(jù)的來源。數(shù)據(jù)收集之后通過消息隊列發(fā)送到日志數(shù)據(jù)服務層進行數(shù)據(jù)預處理，經(jīng)過處理后的數(shù)據(jù)發(fā)送到數(shù)據(jù)庫進行存儲，并建立索引，為用戶提供處理后的日志數(shù)據(jù)以及原始日志數(shù)據(jù)的查詢。

3 系統(tǒng)實現(xiàn)

由于日志數(shù)據(jù)服務框架所具有的層次性，本文采用了多種不同的技術(shù)來滿足不同層次上的服務，如圖3所示。

3.1 日志數(shù)據(jù)資源層

日志數(shù)據(jù)收集服務：資源層負責對原始日志數(shù)據(jù)進行收集，能夠?qū)⑿庐a(chǎn)生的日志數(shù)據(jù)實時發(fā)送到收集端，如圖4是資源層日志數(shù)據(jù)收集的一個具體流程，從圖中可以看出日志收集工作通過分布式收集策略來完成，整個分布式收集結(jié)構(gòu)由子節(jié)點和父節(jié)點以及數(shù)據(jù)庫構(gòu)成，其中每個子節(jié)點由三部分構(gòu)成，包括source、channel、sink，source是數(shù)據(jù)來源，channel是數(shù)據(jù)進行傳輸?shù)耐ǖ?，sink用于將數(shù)據(jù)傳輸?shù)街付ǖ胤?，當每個子節(jié)點上的原始日志數(shù)據(jù)產(chǎn)生后，會通過當前子節(jié)點上的Agent傳遞給對應的日志收集器Collector。日志數(shù)據(jù)收集器Collector具有實時管道傳輸能力，可以處理各式各樣的數(shù)據(jù)，并可以將這些數(shù)據(jù)集中起來以統(tǒng)一的格式發(fā)送到目的地。這三者之間通過event來觸發(fā)和協(xié)調(diào)，當Collector收到數(shù)據(jù)后會對數(shù)據(jù)進行聚合，產(chǎn)生一個更大的數(shù)據(jù)流，最后傳輸?shù)綌?shù)據(jù)庫中。

3.2 日志數(shù)據(jù)服務層

本文的日志數(shù)據(jù)一般分為兩類，第一類就是從各個應用軟件上采集的原始日志數(shù)據(jù)。這類日志數(shù)據(jù)信息量很大但雜亂不堪。本文將這類原始日志數(shù)據(jù)進行歸檔，由于此類數(shù)據(jù)不會被高頻訪問，對實時性要求也不高，因此在規(guī)范化后會存儲到MySQL集群當中。第二類就是通過預處理的日志數(shù)據(jù)，此類數(shù)據(jù)對于故障診斷等日志分析工作有很重要的意義，因此這些數(shù)據(jù)將會被頻繁地訪問。因此這類數(shù)據(jù)本文中考慮存儲到性能較高的分布式數(shù)據(jù)庫Hbase中。如何將關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫結(jié)合，并設計出適合日志數(shù)據(jù)存儲的規(guī)范化數(shù)據(jù)結(jié)構(gòu)是日志數(shù)據(jù)存儲服務的核心部分[11]。

圖2 框架數(shù)據(jù)流

圖3 日志數(shù)據(jù)服務框架技術(shù)實現(xiàn)

圖4 數(shù)據(jù)收集流程圖

關(guān)系型數(shù)據(jù)庫存儲：如表1所示，可以看到的是關(guān)系型數(shù)據(jù)庫MySQL的數(shù)據(jù)庫表設計。

表1 MySQL數(shù)據(jù)庫表

設計完MySQL數(shù)據(jù)庫表后，資源層上的日志數(shù)據(jù)收集服務會將原始日志數(shù)據(jù)導入服務層，先將原始數(shù)據(jù)存入關(guān)系型數(shù)據(jù)庫集群中，在服務層本文調(diào)用日志數(shù)據(jù)存儲服務將數(shù)據(jù)存儲到Mysql集群中，如圖3所示，這里本文中采用了MySQL Cluster來搭建數(shù)據(jù)庫集群。

規(guī)范化日志數(shù)據(jù)：通過日志數(shù)據(jù)收集服務收集原始日志數(shù)據(jù)后，為了方便對原始日志數(shù)據(jù)進行查詢修改，本文將原始日志數(shù)據(jù)發(fā)送到MySQL數(shù)據(jù)庫集群中，原始日志數(shù)據(jù)的格式一般包括如時間-日志等級-發(fā)生的事件，這樣的日志數(shù)據(jù)很不規(guī)范，如果直接將這樣的原始日志數(shù)據(jù)直接存入Hbase數(shù)據(jù)庫，數(shù)據(jù)庫將會浪費大量的時間在解析原始數(shù)據(jù)上，造成整個多層次日志數(shù)據(jù)存儲效率低下，因此必須對日志數(shù)據(jù)格式規(guī)范化，在原始日志數(shù)據(jù)中，每條日志記錄都包含一些主要的信息和次要信息，如一條應用程序的運行日志記錄可能包含：服務ID、服務開始時間、發(fā)生的事件、請求類型等。但對于一般用戶來說，有些信息不是非常重要的，比如服務ID等，有些信息可以通過預處理轉(zhuǎn)化為用戶所需要的信息，因此對于不用的日志數(shù)據(jù)需求，需要進行日志記錄的規(guī)范化處理。

規(guī)范化格式處理是為了達到以下兩個目的：可擴展性、簡單化?？蓴U展性目的是為了容納不同類型的應用程序日志使日志在類型上沒有約束，簡單化是為了規(guī)范化后的日志數(shù)據(jù)在被用戶拿來做日志分析時能夠提高效率，如圖5所示本文將原始日志數(shù)據(jù)格式劃分為三部分：日志索引、日志記錄體以及日志等級。

圖5 日志數(shù)據(jù)結(jié)構(gòu)圖

日志索引是整個日志數(shù)據(jù)存儲格式的核心，為每個日志服務定義一個服務ID，作為主鍵索引便于快速檢索定位日志記錄，提高了預處理以及之后的查詢服務的效率；日志記錄體存放日志數(shù)據(jù)本身的信息，日志記錄體對于日志系統(tǒng)來說是透明的，日志系統(tǒng)通過對這些信息的分析來進行故障診斷；為了更詳細地控制日志數(shù)據(jù)輸出的級別，本文將日志等級分為三個等級INFO、ERROR、DEBUG。如表2所示就是經(jīng)過規(guī)范化后的日志數(shù)據(jù)格式。

表2 規(guī)范化后的日志數(shù)據(jù)格式

在圖3可以看出規(guī)范化后的日志數(shù)據(jù)進入MySQL集群后會分布到不同的ndbd節(jié)點上，然后通過NDB引擎來進行存儲操作。管理節(jié)點（也可以稱管理服務器）主要負責管理數(shù)據(jù)節(jié)點和SQL節(jié)點，還有群集配置文件和群集日志文件。它監(jiān)控其他節(jié)點的工作狀態(tài)，能夠啟動、關(guān)閉或重啟某個節(jié)點。數(shù)據(jù)節(jié)點用于存儲數(shù)據(jù)。SQL節(jié)點跟一般的MySQL服務器是一樣的，可以通過它進行SQL操作。

當原始數(shù)據(jù)存儲到MySQL集群后，隨即導入Spark，通過Spark Streaming對原始數(shù)據(jù)進行過濾、去重和日志記錄分段的預處理工作，Spark Streaming是建立在Spark上的實時計算框架，它將流式計算分解成短小的批處理作業(yè)，交給Spark引擎處理，每一段日志數(shù)據(jù)都轉(zhuǎn)換為Spark中的RDD，然后將Spark Streaming中對DStream的操作變?yōu)獒槍park中對RDD的Transformation的操作。這里用戶可以根據(jù)自己的選擇將自己所需要的日志數(shù)據(jù)記錄通過預處理單獨提取出來，隨后將預處理后的結(jié)果導入Hbase進行存儲。

非關(guān)系型數(shù)據(jù)庫存儲：在HBase中，通過劃分region的方式，來管理大規(guī)模的分布式數(shù)據(jù)庫。預處理后的數(shù)據(jù)會按照記錄為單位存入，本文使用定制的MapReduce Job方式來將預處理后的數(shù)據(jù)導入Hbase。由于HBase底層的文件存儲系統(tǒng)是HDFS。因此仍然具備HDFS高容錯的優(yōu)點，同時HBase提供索引機制，也方便了其他應用訪問日志數(shù)據(jù)[12]。

在本文中根據(jù)日志等級將預處理后的日志數(shù)據(jù)分為3種：INFO、ERROR、DEBUG，分別對應3個表。INFO表通常用一個事物來表示上下文執(zhí)行信息，ERROR表的每一行通常表示一個事物執(zhí)行失敗時產(chǎn)生的上下文執(zhí)行信息，Debug表通常表示一個事物執(zhí)行步驟時所產(chǎn)生的上下文信息。

如表3所示，可以看到的是Hbase的存儲處理后的日志數(shù)據(jù)的邏輯物理設計模型。這里本文選用了日志等級INFO表作為例子。INFO日志記錄信息的字段包括服務ID（ID）、時間戳（Time）、日志等級（Level）、服務時間內(nèi)發(fā)生的事件（Event），通過這種日志存儲模型用戶可以通過日志類型以及服務ID的組合直接獲取到所需要的日志數(shù)據(jù)。

表3 Hbase邏輯物理設計模型

3.3 日志數(shù)據(jù)應用層

日志數(shù)據(jù)查詢服務：經(jīng)過預處理的日志數(shù)據(jù)存儲到Hbase數(shù)據(jù)庫中后，用戶需要對日志數(shù)據(jù)庫進行查詢以便獲得所需要的日志數(shù)據(jù)。Hbase本身只支持基于rowkey的查詢方式，用戶并不知道需要查詢數(shù)據(jù)的rowkey，只能通過關(guān)鍵字對日志數(shù)據(jù)進行查詢，為了滿足用戶的這種多條件查詢需求，本文采用基于Solr的HBase多條件查詢?yōu)橛脩籼峁┓?，通過Solr將HBase數(shù)據(jù)庫中數(shù)據(jù)按照不同條件封裝起來，用戶可以按照不同的需求對經(jīng)過預處理的日志數(shù)據(jù)進行條件查詢，獲得自己所需要的日志數(shù)據(jù)。

如圖6所示，本文將Hbase表中涉及條件過濾的字段和rowkey在Solr中建立索引，通過Solr的多條件查詢快速獲得符合過濾條件的rowkey值，拿到這些rowkey之后在Hbase中通過指定rowkey進行查詢，最后將結(jié)果返回數(shù)據(jù)集給用戶。由于日志數(shù)據(jù)是一種大數(shù)據(jù)量的數(shù)據(jù)，因此傳統(tǒng)的單鍵索引已經(jīng)不適合用于日志數(shù)據(jù)的查詢，因此本文將在Solr上建立一個鍵組合索引，針對規(guī)范化后的日志數(shù)據(jù)的特點，本文在Time、Skype和ID這3個鍵字段上建立索引，并按照Time進行降序排序。

圖6 日志數(shù)據(jù)查詢流程圖

日志查詢服務可以實現(xiàn)根據(jù)關(guān)鍵字和日志產(chǎn)生的時間進行查詢。根據(jù)關(guān)鍵字查詢是指基于特定的語法進行查詢，一句條件篩選符合條件的字段類型或者字段內(nèi)容的日志信息；根據(jù)時間查詢包括相對時間查詢（相對定義的時間點之前時間點的記錄）和絕對時間查詢（自定義時間查詢）。

4 案例研究

為了對本文提出的日志數(shù)據(jù)收集與處理方法進行驗證可行性以及同傳統(tǒng)的日志收集與分析系統(tǒng)進行對比，在一個真實的環(huán)境中進行了案例的部署和研究，測試環(huán)境是由3臺物理機構(gòu)成，這3臺物理機構(gòu)成了一個Spark集群，其中兩臺作為從節(jié)點，一臺作為主節(jié)點，主機的操作系統(tǒng)都為Ubuntu，主節(jié)點作為調(diào)度分配任務存在的，從節(jié)點才是真正計算的部分。主節(jié)點是DELL PowerEdge M630，它有2個6核E5-2609 v3處理器，1.9 GHz，15 MB緩存，64 GB DDR4內(nèi)存，2塊300 GB 10K 2.5′SAS硬盤。從節(jié)點是DELL PowerEdge M630，2個8核Xeon E5-2640 v3處理器，2.6 GHz，20 MB緩存，128 GB DDR4內(nèi)存，2塊300 GB 10K 2.5′SAS硬盤。這些硬件設備之間通過萬兆網(wǎng)卡相連；同時這3臺物理機也搭建了MySQL集群，負責提供關(guān)系型數(shù)據(jù)庫服務。

本文所用的數(shù)據(jù)來源采用了某綜合減災空間信息服務應用系統(tǒng)的日志數(shù)據(jù)，該應用系統(tǒng)的目標是從空間和時間的維度可視化自然災害的風險和損失，為各項災害管理工作各階段提供直觀的信息，并提供產(chǎn)品、技術(shù)、決策等服務，保障了防災減災工作的有效進行。該應用系統(tǒng)采用面向服務的體系架構(gòu)（SOA），包含一系列具有獨立功能的Web組件。本文從該系統(tǒng)得到的數(shù)據(jù)分為三種，分別為樣本數(shù)據(jù)（100 MB）、一個月的數(shù)據(jù)（700 MB）、一年的完整數(shù)據(jù)（4.96 GB）。日志數(shù)據(jù)收集與服務處理框架應用案例如圖7所示。

4.1 日志數(shù)據(jù)處理流程

由圖7可以看出在本案例中日志數(shù)據(jù)資源層負責收集某綜合減災空間信息服務應用系統(tǒng)產(chǎn)生的日志數(shù)據(jù)，收集到的原始日志數(shù)據(jù)如圖8所示。

經(jīng)過規(guī)范化后Spark分布式處理系統(tǒng)會調(diào)用MySQL中的原始數(shù)據(jù)，通過RDD模塊進行日志數(shù)據(jù)預處理，再將處理過的數(shù)據(jù)存儲到Hbase數(shù)據(jù)庫中。預處理后的日志數(shù)據(jù)如表4所示。

圖7 日志數(shù)據(jù)收集與服務處理框架應用案例

表4 預處理后的日志數(shù)據(jù)

圖8 原始日志數(shù)據(jù)

如表4可以看到Hbase的數(shù)據(jù)庫表和字段，最后用戶通過應用層提供的日志數(shù)據(jù)查詢服務得到精確化的日志數(shù)據(jù)。如圖9所示，用戶查詢了在時間點之間的Error日志，結(jié)果會返回在這個時間點之間發(fā)生錯誤的時間以及發(fā)生錯誤的服務ID。由以上可知，本文提出的日志收集與服務處理框架能夠有效地完成對日志數(shù)據(jù)收集與處理的任務，并向用戶提供所需要的查詢結(jié)果。從而驗證了本文提出的日志數(shù)據(jù)收集與服務處理框架的實用性。

本文選用通過JSON數(shù)據(jù)格式給出，因為JSON是一種輕量級的數(shù)據(jù)交換格式，采用完全獨立于語言的文本格式，易于閱讀和編寫，同時也易于數(shù)據(jù)解析，傳輸JSON格式的日志數(shù)據(jù)帶來的傳輸負載很小，非常符合日志數(shù)據(jù)傳輸?shù)囊?。如圖10所示，截取了一段用戶查詢的處理后的日志數(shù)據(jù)。

圖9 日志數(shù)據(jù)查詢結(jié)果

圖10 預處理后日志數(shù)據(jù)查詢結(jié)果

4.2 實用性測試

為了測試查詢服務的效率，這里對不同數(shù)據(jù)量下的日志數(shù)據(jù)進行數(shù)據(jù)查詢，比較響應時間和響應數(shù)。本文以日志記錄的條數(shù)為基準比較不同數(shù)據(jù)量下，每個請求的時長。

從圖11中可以看出，日志數(shù)據(jù)量的增大，導致查詢的響應時間呈現(xiàn)出先減后升的趨勢，這是因為日志查詢服務會對查詢結(jié)果進行緩存，可以看到當用戶查詢?nèi)罩緮?shù)量達到50 000條時，響應時間仍然保持在80 ms水平，說明了整個查詢服務能夠保證良好的用戶體驗。

圖11 日志數(shù)據(jù)查詢測試結(jié)果

4.3 對比分析

為了評價本文日志框架的價值，同常用的ELK分布式日志系統(tǒng)以及Chukwa進行對比，ELK是一種日志收集分析平臺，由ElasticSearch、Logstash和Kiabana 3個開源工具組成，所以被稱為ELK。chukwa是一個開源的用于監(jiān)控大型分布式系統(tǒng)的數(shù)據(jù)收集系統(tǒng)。這是構(gòu)建在hadoop的hdfs和map/reduce框架之上的，繼承了hadoop的可伸縮性和魯棒性。Chukwa還包含了一個強大和靈活的工具集，可用于展示、監(jiān)控和分析已收集的數(shù)據(jù)。這里對日志數(shù)據(jù)處理日志數(shù)據(jù)所占用的時間與CPU利用率進行比較，實驗使用系統(tǒng)監(jiān)控工具Nagios對兩者分別監(jiān)控。如圖12所示，隨著日志數(shù)據(jù)集的不斷增大，整個CPU的利用率會緩慢提高。日志數(shù)量達到50 000條時，Chukwa的CPU使用率達到了25.3%，ELK的CPU使用率達到了22.6%，而本文的日志框架的CPU使用率達到了22.3%，可以看出三者之間沒有太大的區(qū)別，但隨著日志數(shù)量的不斷增多，本文的日志框架CPU使用率相比其他兩者略有降低，因此從CPU使用率來看本文中的日志框架在處理大數(shù)據(jù)量日志數(shù)據(jù)時相對這些已經(jīng)成熟使用的日志收集分析系統(tǒng)來說有一定優(yōu)勢。

圖12 CPU使用率對比圖

圖13是對以上三種不同日志收集分析系統(tǒng)，從處理日志數(shù)據(jù)到查詢?nèi)罩緮?shù)據(jù)結(jié)束所占用的時間進行了比較。這里本文對1到100個日志文件進行測試，每個文件單位時間內(nèi)所產(chǎn)生的日志數(shù)據(jù)量為30 kb，同時在不同時間段內(nèi)進行采樣，最終取平均值，實驗結(jié)果如下：隨著日志文件的增多每條記錄從產(chǎn)生到進行日志處理與查詢所耗費的時間也隨之增大，當達到50個日志文件時，本文的日志框架所消耗的時間同ElK與Chukwa所消耗的時間相比略長，但到100個日志文件時，所消耗的時間相比ELK與Chukwa已經(jīng)有所減少，因此可以說明在處理大數(shù)據(jù)量日志數(shù)據(jù)時本文提出的框架相比傳統(tǒng)的ELK以及Chukwa有一定優(yōu)勢。

圖13 處理時間對比圖

5 結(jié)束語

應用程序運行過程中會產(chǎn)生大量的操作痕跡，如何快速地收集這些日志操作痕跡去生成日志數(shù)據(jù)，存儲日志數(shù)據(jù)，并根據(jù)這些日志數(shù)據(jù)向用戶提供下一步的服務，具有很大的意義。本文提出了一種面向應用層程序運行日志的收集與服務處理框架，該方法利用分布式收集策略實現(xiàn)了針對應用程序的運行日志的收集，利用Spark對日志數(shù)據(jù)進行預處理，并且利用了Hbase數(shù)據(jù)庫以及MySQL數(shù)據(jù)庫集群實現(xiàn)了對日志數(shù)據(jù)的存儲，最后通過自定義的日志服務向用戶提供日志數(shù)據(jù)查詢。相比傳統(tǒng)的日志收集處理方案，這種日志收集與服務處理框架有諸多優(yōu)點：首先，日志數(shù)據(jù)采用實時采集并通過數(shù)據(jù)庫保存，因此可以對某些數(shù)據(jù)進行實時分析。其次，該框架考慮到日志數(shù)據(jù)的特點，采用大數(shù)據(jù)平臺對日志數(shù)據(jù)進行處理，并通過多層次的數(shù)據(jù)庫存儲來滿足不同類型日志數(shù)據(jù)的存儲需求。最后，該框架可以滿足用戶的個性化需求。在接下來的研究工作中，將進一步考慮如何進一步降低本文框架處理日志數(shù)據(jù)時CPU使用率的問題，并且提高整個框架的穩(wěn)定性。

：

[1]付博，趙世奇，劉挺.Web查詢?nèi)罩狙芯烤C述[J].電子學報，2013，41（9）：1800-1808.

[2]Fu Q，Zhu J，Hu W，et al.Where do developers log?An empiricalstudy on logging practices in industry[C]//36th International Conference on Software Engineering（ICSE），2014：24-33.

[3]廖湘科，李姍姍，董威，等.大規(guī)模軟件系統(tǒng)日志研究綜述[J].軟件學報，2016，27（8）：1934-1947.

[4]韋勇，連一峰.基于日志審計與性能修正算法的網(wǎng)絡安全態(tài)勢評估模型[J].計算機學報，2009，32（4）：763-772.

[5]劉虎球，馬超，白家駒.面向驅(qū)動配置的自動日志插入方法研究[J].計算機學報，2013，36（10）：1982-1992.

[6]李玉榮，楊樹強，賈焰，等.分布式日志服務關(guān)鍵技術(shù)研究[J].計算機工程與應用，2006，42（7）：116-118.

[7]周江，王偉平，孟丹，等.面向大數(shù)據(jù)分析的分布式文件系統(tǒng)關(guān)鍵技術(shù)[J].計算機研究與發(fā)展，2014，51（2）：382-394.

[8]申利民，張旭暉.面向SAAS模式的日志架構(gòu)設計與實現(xiàn)[J].計算機應用與軟件，2011，28（12）：57-59.

[9]崔杰，李陶深，蘭紅星.基于Hadoop的海量數(shù)據(jù)存儲平臺設計與開發(fā)[J].計算機研究與發(fā)展，2012，49（s1）：12-18.

[10]鐘武，胡守仁.一種分布式數(shù)據(jù)庫查詢優(yōu)化算法[J].計算機學報，1997（11）：1024-1033.

[11]薛永慶，徐維祥.一種適應大型數(shù)據(jù)庫的多支持度關(guān)聯(lián)規(guī)則算法[J].計算機工程與應用，2008，44（2）：182-185.

[12]宛婉，周國祥.Hadoop平臺的海量數(shù)據(jù)并行隨機抽樣[J].計算機工程與應用，2014，50（20）：115-118.

[13]Zhu Jieming，He Pinjia，F(xiàn)u Qiang，et al.Learning to log：helping developers make informed logging decisions[C]//IEEE/ACM 37th IEEE International Conference on Software Engineering，2015：415-425.

[14]Cinque M，Cotroneo D，Pecchia A.Event logs for the analysis of software failures：a rule-based approach[J].IEEE Transactions on Software Engineering，2013，39.

[15]Lan Z，Zheng Z，Li Y.Toward automated anomaly identification in large-scale systems[J].IEEE Transactions on Parallel&Distributed Systems，2010，21（2）：174-187.

[16]Rabkin A，Xu W，Wildani A，et al.A graphical representation for identifier structure in logs[C]//The Workshop on Managing Systems Via Log Analysis&Machine Learning，2010.

[17]Salfner F，Tschirpke S，Malek M.Comprehensive logfiles for autonomic systems[C]//International Parallel and Distributed Processing Symposium，2004.