應(yīng)用軟件運(yùn)行日志的收集與服務(wù)處理框架

張 驍，應(yīng) 時(shí) ，張 韜

1.武漢大學(xué) 軟件工程國家重點(diǎn)實(shí)驗(yàn)室，武漢 430072

2.武漢大學(xué) 計(jì)算機(jī)學(xué)院，武漢 430072

3.中國移動(dòng)通信集團(tuán) 湖北有限公司，武漢 430023

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

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

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

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

1 相關(guān)工作

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

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

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

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

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

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

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

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

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

該框架具有以下幾個(gè)特性：

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

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

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

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

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

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

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

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

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

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

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

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

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

日志數(shù)據(jù)存儲(chǔ)服務(wù)：日志數(shù)據(jù)存儲(chǔ)服務(wù)是服務(wù)層的一個(gè)重要構(gòu)成部分，負(fù)責(zé)對(duì)原始數(shù)據(jù)以及預(yù)處理后的數(shù)據(jù)進(jìn)行存儲(chǔ)。應(yīng)用軟件的運(yùn)行日志具有以下特點(diǎn)[9]：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表3 Hbase邏輯物理設(shè)計(jì)模型

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

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

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

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

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

4 案例研究

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

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

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

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

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

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

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

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

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

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

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

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

4.2 實(shí)用性測(cè)試

為了測(cè)試查詢服務(wù)的效率，這里對(duì)不同數(shù)據(jù)量下的日志數(shù)據(jù)進(jìn)行數(shù)據(jù)查詢，比較響應(yīng)時(shí)間和響應(yīng)數(shù)。本文以日志記錄的條數(shù)為基準(zhǔn)比較不同數(shù)據(jù)量下，每個(gè)請(qǐng)求的時(shí)長。

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

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

4.3 對(duì)比分析

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

圖12 CPU使用率對(duì)比圖

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

圖13 處理時(shí)間對(duì)比圖

5 結(jié)束語

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

：

[1]付博，趙世奇，劉挺.Web查詢?nèi)罩狙芯烤C述[J].電子學(xué)報(bào)，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]廖湘科，李?yuàn)檴櫍?大規(guī)模軟件系統(tǒng)日志研究綜述[J].軟件學(xué)報(bào)，2016，27（8）：1934-1947.

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

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

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

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

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

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

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

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

[12]宛婉，周國祥.Hadoop平臺(tái)的海量數(shù)據(jù)并行隨機(jī)抽樣[J].計(jì)算機(jī)工程與應(yīng)用，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.