基于Docker的大規(guī)模日志采集與分析系統(tǒng)①

羅東鋒 ,李 芳 ,郝汪洋 ,吳仲城

1(中國科學(xué)院 強(qiáng)磁場科學(xué)中心,合肥 230031)2(中國科學(xué)技術(shù)大學(xué),合肥 230026)

基于Docker的大規(guī)模日志采集與分析系統(tǒng)①

羅東鋒1,2,李 芳1,郝汪洋1,2,吳仲城1

1(中國科學(xué)院 強(qiáng)磁場科學(xué)中心,合肥 230031)2(中國科學(xué)技術(shù)大學(xué),合肥 230026)

傳統(tǒng)日志分析技術(shù)在處理大規(guī)模日志時存在效率低、功能簡單、實際應(yīng)用擴(kuò)展性弱等問題.為解決這些問題,設(shè)計了基于Docker的大規(guī)模日志采集與分析系統(tǒng).系統(tǒng)分為數(shù)據(jù)采集、數(shù)據(jù)緩存、數(shù)據(jù)轉(zhuǎn)發(fā)、數(shù)據(jù)存儲、數(shù)據(jù)檢索和展示五層,支持從不同數(shù)據(jù)源采集各種類型的日志,通過Kafka消息隊列提供可靠數(shù)據(jù)傳輸,利用Elasticsearch實現(xiàn)數(shù)據(jù)分布式存儲和檢索,并以可視化方式分析日志.同時采用Docker容器技術(shù)實現(xiàn)系統(tǒng)的快速部署和版本控制.該系統(tǒng)具有實時性、可擴(kuò)展性、易部署等特點.實驗結(jié)果表明了該系統(tǒng)可行有效,具有良好的實用價值.

日志采集與分析; Docker; elasticsearch; 開源; 可擴(kuò)展性; 實時

1 引言

隨著大數(shù)據(jù)時代的到來,數(shù)據(jù)的重要性日益凸顯,大數(shù)據(jù)的研究和應(yīng)用[1]帶來了巨大的商業(yè)價值和社會價值.日志是互聯(lián)網(wǎng)企業(yè)日常運營生產(chǎn)和積累的海量數(shù)據(jù)中最有價值的數(shù)據(jù)之一.根據(jù)日志的來源和類型的不同,日志大致劃分為系統(tǒng)日志、應(yīng)用業(yè)務(wù)日志和安全日志這三類.通過系統(tǒng)日志能夠有效監(jiān)控系統(tǒng)的運行狀況,及時發(fā)現(xiàn)及解決潛在的問題,提高系統(tǒng)的服務(wù)質(zhì)量.應(yīng)用業(yè)務(wù)日志包含業(yè)務(wù)信息和用戶訪問信息,可用于分析用戶行為[2].安全日志用于安全審計及取證,發(fā)現(xiàn)攻擊或者非法操作行為,提高系統(tǒng)的安全性.日志通常帶有時間戳的屬性,是遞增的事件序列.隨著用戶量的增長和用戶需求的不斷變化,互聯(lián)網(wǎng)應(yīng)用系統(tǒng)的規(guī)模不斷擴(kuò)大、復(fù)雜度不斷加深,系統(tǒng)產(chǎn)生的日志數(shù)據(jù)量也在急劇增長.大規(guī)模日志的實時收集、存儲和分析仍然面臨諸多問題和挑戰(zhàn):

① 日志種類繁多,比如Tomcat服務(wù)器日志、Nginx服務(wù)器日志、MySQL數(shù)據(jù)庫日志、操作系統(tǒng)日志等,由于格式不一致導(dǎo)致分析困難;

② 日志來源分散,不僅存在于不同的服務(wù)器,而且分布在同一服務(wù)器的不同文件中;

③ 日志產(chǎn)生的速度快,占用服務(wù)器的存儲空間不斷增加;

④ 日志具有時效性,日志產(chǎn)生后需要在短時間內(nèi)進(jìn)行分析;

⑤ 缺乏有效的日志可視化分析手段.

針對上述問題,日志分析系統(tǒng)在處理速度、可擴(kuò)展性、實時性、分析緯度等方面提出了更高的要求.隨著大數(shù)據(jù)技術(shù)的發(fā)展,有不少新的日志采集分析方案被提出.Scribe[3]是Facebook開源的一個基于Thrift遠(yuǎn)程服務(wù)調(diào)用框架的日志收集系統(tǒng),它為日志分布式收集、統(tǒng)一處理提供一個可擴(kuò)展的簡單方案.但Scribe存在單點故障問題,比如中央服務(wù)器異常退出會造成內(nèi)存中數(shù)據(jù)的丟失,Facebook已經(jīng)不再更新和維護(hù)Scribe.Apache Chukwa[4]是一個用以監(jiān)控大型分布式系統(tǒng)的開源數(shù)據(jù)收集系統(tǒng),它是基于Hadoop的HDFS和Map/Reduce框架之上構(gòu)建的,具備可伸縮性和魯棒性.由于依賴于Map/Reduce框架去處理數(shù)據(jù),導(dǎo)致數(shù)據(jù)流在數(shù)據(jù)處理間斷時吞吐量急劇下降,嚴(yán)重影響效率.趙龍等人利用Hadoop分布式計算平臺和Hive數(shù)據(jù)倉庫進(jìn)行日志分析[5].該方法采用批處理的方式處理數(shù)據(jù),實時性較差,適合于數(shù)據(jù)離線挖掘,且不支持全文檢索.結(jié)合現(xiàn)有各類日志采集分析系統(tǒng)的研究基礎(chǔ),本文基于Docker容器技術(shù),設(shè)計了一種分層且可擴(kuò)展的日志系統(tǒng),實現(xiàn)大規(guī)模互聯(lián)網(wǎng)應(yīng)用場景下的日志快速分析.

2 系統(tǒng)架構(gòu)設(shè)計

系統(tǒng)整體結(jié)構(gòu)分為數(shù)據(jù)采集層、數(shù)據(jù)緩存層、數(shù)據(jù)轉(zhuǎn)發(fā)層、數(shù)據(jù)存儲層、數(shù)據(jù)檢索和展示層,如圖1所示.數(shù)據(jù)采集層從不同的數(shù)據(jù)源中實時獲取最新的日志信息,并對其進(jìn)行預(yù)處理后依次傳輸?shù)綌?shù)據(jù)緩存層.數(shù)據(jù)轉(zhuǎn)發(fā)層實時從緩存層拉取數(shù)據(jù)轉(zhuǎn)發(fā)到數(shù)據(jù)存儲層.數(shù)據(jù)存儲層把接收的數(shù)據(jù)寫入磁盤,并建立索引庫.數(shù)據(jù)檢索和展示層連接到數(shù)據(jù)存儲層,提供統(tǒng)一的日志信息查詢和分析入口.

圖1 日志采集與分析系統(tǒng)架構(gòu)

系統(tǒng)各層利用Docker容器虛擬化技術(shù),實現(xiàn)應(yīng)用程序的快捷部署,并且支持橫向擴(kuò)展,以便應(yīng)對更大規(guī)模的日志收集、存儲和分析.基于該系統(tǒng)架構(gòu),系統(tǒng)各層之間通過網(wǎng)絡(luò)傳輸方式進(jìn)行交互,實現(xiàn)系統(tǒng)層級的獨立解耦.

2.1 Docker容器虛擬化技術(shù)

Docker[6]是 Docker,Inc.公司開源的一個基于 Go語言編寫的輕量級應(yīng)用容器引擎,用于自動化部署應(yīng)用.Docker容器通過將應(yīng)用和該應(yīng)用運行所依賴的系統(tǒng)庫、系統(tǒng)工具、源碼等均打包到一個文件系統(tǒng)中,從而確保了應(yīng)用在任何環(huán)境下均能實現(xiàn)一致性的運行效果.用戶可在宿主機(jī)部署運行多個Docker容器,每個容器擁有自己的資源并與其它容器相互隔離,容器之間支持相互通信.Docker采用類似于Git版本控制系統(tǒng)的思想,實現(xiàn)對Docker鏡像(Image)的版本管理,比如通過docker commit命令從容器創(chuàng)建一個新的鏡像.此外,在絕大多數(shù)情況下Docker容器的性能優(yōu)于傳統(tǒng)虛擬機(jī)KVM,接近原生的性能[7].

根據(jù)Docker的工作流程圖(圖2),Docker的生命周期主要包括鏡像(Image)、Docker倉庫(Repository)、容器(Container)三個部分.Dockerfile由一系列指令組成,用于自動創(chuàng)建 Docker鏡像.Docker鏡像可以理解為一個只讀模板,而容器是由鏡像創(chuàng)建的運行實例,具有運行、暫停、停止三種狀態(tài).Docker容器負(fù)責(zé)運行以及隔離應(yīng)用程序.Docker注冊服務(wù)器(Registry)是用來存放各種倉庫的中心,每個倉庫集中存放某一類鏡像,每個鏡像文件擁有對應(yīng)的標(biāo)簽(tag).倉庫又分為公有倉庫和私有倉庫,用戶創(chuàng)建鏡像后可以通過push上傳到倉庫,需要時再用pull從倉庫中下載.用戶既可在公有倉庫發(fā)布鏡像,也可部署自己的私倉倉庫發(fā)布鏡像.另外,鏡像制作遵循復(fù)用原則,在其他鏡像的基礎(chǔ)上進(jìn)行構(gòu)建.

圖2 Docker工作流程圖

在容器數(shù)據(jù)管理方面,Docker通過掛載宿主系統(tǒng)文件或文件目錄作為數(shù)據(jù)卷(Volume)實現(xiàn)與宿主系統(tǒng)數(shù)據(jù)共享,也可以通過數(shù)據(jù)卷容器實現(xiàn)容器之間的數(shù)據(jù)共享.舉個例子,下面一條命令表示運行一個Elasticsearch容器,并將宿主系統(tǒng)/home/elasticsearch/config目錄掛載到它的/usr/share/elasticsearch/config目錄:

docker run -d -v/home/elasticsearch/config:/usr/share/elasticsearch/config elasticsearch:2.4.1

2.2 數(shù)據(jù)采集層

數(shù)據(jù)采集是日志分析的基礎(chǔ).日志分散在各個服務(wù)器上不同文件中,其類型也不一定相同.數(shù)據(jù)采集工具從不同的數(shù)據(jù)源獲取日志信息,進(jìn)行預(yù)處理后傳送到數(shù)據(jù)緩存層.通常一條日志記錄包含時間戳、來源和數(shù)據(jù).時間戳表示一條日志記錄生成的時間.來源標(biāo)識產(chǎn)生該條日志的系統(tǒng).數(shù)據(jù)就是日志信息中最核心的內(nèi)容.但這種格式并不是一個標(biāo)準(zhǔn),不同系統(tǒng)產(chǎn)生的日志格式也各不相同.為獲得有價值且便于分析的日志信息,需要對原始日志進(jìn)行預(yù)處理.預(yù)處理主要是對日志進(jìn)行過濾和加工操作.比如只傳輸符合規(guī)則的日志行,給日志行添加用以區(qū)分來源的字段等.日志實時采集傳送到數(shù)據(jù)緩存層,已采集的日志文件可定期刪除,而不必在服務(wù)器存儲原始日志文件,有效減輕了服務(wù)器的負(fù)載.

目前主流的開源數(shù)據(jù)收集工具有Logstash、Fluentd等.Logstash是實時收集、加工、轉(zhuǎn)發(fā)數(shù)據(jù)的工具,支持處理各種常見類型的日志.根據(jù)不同的功能,Logstash分為日志收集者和日志轉(zhuǎn)發(fā)者.本文中日志收集者負(fù)責(zé)從日志文件中實時讀取最新的行文本,處理后輸出到數(shù)據(jù)緩存層.而日志轉(zhuǎn)發(fā)者從數(shù)據(jù)緩存層中拉取數(shù)據(jù),加工處理后轉(zhuǎn)發(fā)到數(shù)據(jù)存儲層.同樣,Fluentd[8]也具備日志收集和日志轉(zhuǎn)發(fā)的功能.Fluentd有 Input、Parser、Filter、Output、Formatter和Buffer六種類型的插件,通過靈活的插件機(jī)制,實現(xiàn)多種數(shù)據(jù)源的輸入和輸出.Fluentd還支持基于內(nèi)存和基于文件的緩存,以防止內(nèi)部節(jié)點數(shù)據(jù)的丟失,也支持故障轉(zhuǎn)移.表1為這兩種數(shù)據(jù)采集工具的比較.

表1 Logstash 與 Fluentd 對比

基于可靠性和性能的考慮,本系統(tǒng)采用Fluentd實現(xiàn)數(shù)據(jù)采集層.Fluentd配置文件示例如下:

該配置文件包括source指令和match指令.source指令中指定從文件中讀取數(shù)據(jù),match指令則配置了數(shù)據(jù)輸出目的地為Kafka服務(wù)器.

2.3 數(shù)據(jù)緩存層

為了解決數(shù)據(jù)采集的吞吐量超過數(shù)據(jù)處理容量而造成數(shù)據(jù)的丟失,在數(shù)據(jù)采集層和數(shù)據(jù)轉(zhuǎn)發(fā)層之間添加一層數(shù)據(jù)緩存層.該緩存層采用消息隊列的技術(shù)實現(xiàn),提高了系統(tǒng)的性能和可靠性.目前提供消息隊列服務(wù)的工具,主流的有 Redis 和 Kafka.Redis[9]是一個開源、高性能、基于內(nèi)存的鍵值對數(shù)據(jù)庫.它支持?jǐn)?shù)據(jù)的持久化和訂閱發(fā)布機(jī)制等高級特性.Kafka[10]是一種開源分布式發(fā)布訂閱消息系統(tǒng),具有高性能、高吞吐率、水平擴(kuò)展等特性.Kafka支持?jǐn)?shù)據(jù)離線處理和實時處理.本文選用Kafka消息隊列實現(xiàn)數(shù)據(jù)緩存層,因為Kafka提供消息持久化能力和容錯性保證,在可靠性方面優(yōu)于Redis.Redis不保存已發(fā)送出去的消息,而 Kafka 可保存被消費的消息的副本.此外,Kafka在處理海量日志方面更具優(yōu)勢,Kafka利用磁盤存儲消息隊列的數(shù)據(jù),而Redis則受物理內(nèi)存的限制.在消息壓縮方面,Kafka支持snappy、gzip等多種壓縮方式.盡管消息壓縮需要消耗少量的CPU資源,但是由于大規(guī)模的日志傳輸瓶頸主要在于網(wǎng)絡(luò)IO,啟用消息壓縮機(jī)制能夠有效減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量,提高日志傳輸效率.

在集群方面,Kafka使用ZooKeeper(分布式協(xié)調(diào)服務(wù)框架)實現(xiàn)Kafka各組件的服務(wù)協(xié)調(diào).Kafka發(fā)布訂閱的對象是話題(Topic),一個話題就是一類消息,Kafka通過從物理上劃分一個或多個分區(qū)(Partition)實現(xiàn)對話題的管理.Kafka實現(xiàn)了一個分區(qū)內(nèi)消息的有序性,但不能保證不同分區(qū)之間的消息有序.Kafka為同一數(shù)據(jù)源的所有日志創(chuàng)建一個話題.本系統(tǒng)為保證一個話題中所有消息的有序性,將該話題的分區(qū)數(shù)設(shè)置為一個.發(fā)送消息到話題的一方稱為生產(chǎn)者(Producer).數(shù)據(jù)采集層就是消息隊列的消息生產(chǎn)者.而消費者(Consumer)是訂閱話題消費消息的一方.若話題中只有一個分區(qū),消費者消費該話題中消息的順序與該分區(qū)中消息先后順序一致.一個Kafka集群由一個或多個代理(Broker)服務(wù)器組成.Kafka的容錯性是通過副本(Replica)機(jī)制實現(xiàn).Kafka允許用戶為每一個話題設(shè)置副本數(shù)量.副本是以分區(qū)為單位創(chuàng)建的.每個分區(qū)可以有一個或多個副本,每個副本保存在不同的代理上.若分區(qū)只有一個副本,則該副本就是領(lǐng)導(dǎo)者(leader),負(fù)責(zé)處理該分區(qū)的讀寫請求.若分區(qū)中有多個副本,則其中一個副本會被選舉為領(lǐng)導(dǎo)者,其他的副本則充當(dāng)跟隨者(follower)的角色.跟隨者會被動去復(fù)制領(lǐng)導(dǎo)者上的數(shù)據(jù).當(dāng)領(lǐng)導(dǎo)者發(fā)生故障時,會從這些跟隨者中選舉新的領(lǐng)導(dǎo)者.

2.4 數(shù)據(jù)轉(zhuǎn)發(fā)層

數(shù)據(jù)轉(zhuǎn)發(fā)層作為數(shù)據(jù)緩存層中消息隊列的消息消費者,從消息隊列中拉取消息并轉(zhuǎn)發(fā)到數(shù)據(jù)存儲層進(jìn)行處理.Fluentd作為數(shù)據(jù)轉(zhuǎn)發(fā)層進(jìn)行日志消息的拉取和轉(zhuǎn)發(fā).為降低海量日志對數(shù)據(jù)存儲帶來的沖擊,數(shù)據(jù)轉(zhuǎn)發(fā)層首先通過正則表達(dá)式對待分析的日志進(jìn)行匹配,過濾無用的日志信息,僅對關(guān)注的日志進(jìn)行提取和轉(zhuǎn)發(fā).

以Nginx訪問日志為例,日志各字段含義如圖3中標(biāo)注所示.若使用Fluentd對此類型的日志提取數(shù)據(jù),可采用以下正則表達(dá)式進(jìn)行匹配:

^(?S+)s-s-s[(?[^]]*)]s"(?[^"]+)"s(?d+)s(?d+)?$

圖3 Nginx 訪問日志

在數(shù)據(jù)提取時,通過正則表達(dá)式匹配后的各字段被提取出來并命名.例如,日志中的客戶端IP地址被命名為client_ip,訪問時間與時區(qū)被命名為timestamp.通過對字段進(jìn)行命名,有利于為后續(xù)日志分析提供關(guān)鍵信息.

2.5 數(shù)據(jù)存儲層

數(shù)據(jù)存儲層是本系統(tǒng)最核心的一層.數(shù)據(jù)轉(zhuǎn)發(fā)層將轉(zhuǎn)發(fā)的日志逐條插入到數(shù)據(jù)存儲層的Elasticsearch集群.Elasticsearch[11]是一個高可用、高伸縮、基于Apache Lucene的開源分布式搜索和分析引擎.雖然Elasticsearch與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(Rational Database)存在很大的差異性,但是兩者在一些核心概念上有相似之處,見表2.

表2 Elasticsearch 和 Rational Database 對比

Elasticsearch既支持全文檢索,也可以存儲數(shù)據(jù).它存儲不依賴模式(Schema)的JSON(JavaScript Object Notation)文檔,并對每一個文檔進(jìn)行索引.一條日志對應(yīng)一個文檔.Elasticsearch運行在Java虛擬機(jī)之上,通過RESTful API接口的方式對數(shù)據(jù)進(jìn)行增刪改查操作.操作時,若有參數(shù)輸入,參數(shù)的格式以JSON形式表示,操作后輸出的結(jié)果也是以JSON形式顯示.圖4表示使用curl命令刪除一條文檔.可以看得出RESTful風(fēng)格的API結(jié)構(gòu)清晰、易于理解.

圖4 curl命令刪除一條文檔

Elasticsearch是分布式的,可通過管理節(jié)點(Node)實現(xiàn)擴(kuò)展.節(jié)點是運行Elasticsearch的實例.一個集群(Cluster)是一組具有相同集群名稱的節(jié)點集合.集群中節(jié)點可以配置為主節(jié)點、數(shù)據(jù)節(jié)點和客戶端節(jié)點這三種不同的角色.主節(jié)點控制集群,負(fù)責(zé)集群的管理工作,比如創(chuàng)建或刪除數(shù)據(jù)索引.數(shù)據(jù)節(jié)點負(fù)責(zé)存儲數(shù)據(jù)分片和數(shù)據(jù)操作,比如數(shù)據(jù)分片增刪改查操作.客戶端節(jié)點將到來的請求轉(zhuǎn)發(fā)到集群的其他節(jié)點,起到負(fù)載均衡的作用.

當(dāng)集群需要存儲超出單個機(jī)器容量的數(shù)據(jù)時,Elasticsearch會自動將數(shù)據(jù)分別發(fā)送至多個存儲Lucene索引的機(jī)器上,這些Lucene索引稱為分片(Shard)索引.同時Elasticsearch通過副本(Replica)機(jī)制對分片進(jìn)行數(shù)據(jù)冗余,保證了集群的高可用.另外,Elasticsearch 支持插件機(jī)制,包含豐富且功能強(qiáng)大的插件.在分析含有中文內(nèi)容的日志時,需要對中文檢索,而Elasticsearch內(nèi)置的標(biāo)準(zhǔn)分析器對中文分詞支持相對較弱.它在處理分詞時,將中文的每一個漢字作為一個詞(token)分開,這種方式搜索的結(jié)果查全率非常高,而查準(zhǔn)率很低,無法滿足復(fù)雜或者特定的中文搜索需求.本系統(tǒng)中Elasticsearch采用IK analyzer中文分詞器[12]進(jìn)行中文搜索,效果較為理想.

2.6 數(shù)據(jù)檢索和展示層

僅從每一條日志信息中難以發(fā)現(xiàn)海量日志中隱含的規(guī)律.數(shù)據(jù)檢索和展示層為數(shù)據(jù)存儲層中所有日志信息提供統(tǒng)一的查詢?nèi)肟?并可對日志進(jìn)行統(tǒng)計分析以可視化形式呈現(xiàn)結(jié)果.日志可視化將復(fù)雜和抽象的日志信息轉(zhuǎn)成圖表形式,使得用戶更容易理解日志之間的聯(lián)系和變化情況,便于用戶更好地做出決策.Kibana和Grafana都支持Elasticsearch數(shù)據(jù)可視化展示.Grafana是開源的可視化測量數(shù)據(jù)的工具,但對Elasticsearch數(shù)據(jù)檢索支持較弱.而Kibana是基于Apache License2.0開源協(xié)議,使用HTML語言和JavaScript編寫,可提供數(shù)據(jù)分析和可視化的Web前端應(yīng)用.它可以對Elasticsearch中的數(shù)據(jù)進(jìn)行搜索、分析和以統(tǒng)計圖表的方式展示結(jié)果.Kibana的查詢語法是基于Lucene的查詢語法,通過布爾運算符、通配符和字段篩選進(jìn)行模式匹配搜索.用戶可選擇對查詢的結(jié)果進(jìn)行保存,方便以后再次查看.Kibana可以實時查看數(shù)據(jù)存儲層中最新存儲的日志信息.

3 實驗測試及結(jié)果分析

本文重點驗證系統(tǒng)整體的有效性以及Fluentd的數(shù)據(jù)采集效率.通過部署在同一局域網(wǎng)的9臺PC機(jī)搭建集群進(jìn)行測試.每臺PC機(jī)的硬件環(huán)境為主頻3.1 GHz的四核 CPU、內(nèi)存 4 GB、磁盤 200 GB,軟件環(huán)境為CentOS7.2(64 bit)、Docker1.10.3、JDK1.8.0_65、Kafka2.11-0.10.0.1、Elasticsearch2.4.1、Kibana4.6.2、ZooKeeper3.4.9、Fluentd0.12.30.圖5為本次實驗系統(tǒng)部署架構(gòu),集群各個節(jié)點的配置及其功能描述如表3所示.實驗數(shù)據(jù)集為模擬Nginx日志和Tomcat日志,實驗時不斷地往被收集的日志文件中寫日志.

圖5 系統(tǒng)部署架構(gòu)圖

表3 系統(tǒng)集群配置情況

經(jīng)過測試,Fluentd的內(nèi)存使用率變化不大,大概占2%左右.Fluentd數(shù)據(jù)采集速率與CPU使用率基本上呈線性關(guān)系,峰值數(shù)據(jù)采集速率可達(dá)2.7萬條日志/秒.數(shù)據(jù)產(chǎn)生到數(shù)據(jù)展示耗時30秒以內(nèi),基本滿足日志分析實時性的需求.在Kibana中可以看到最新收集的日志信息,并能以圖表形式進(jìn)行統(tǒng)計分析,圖6為統(tǒng)計某一時間段客戶端IP訪問次數(shù).

圖6 統(tǒng)計某一時間段客戶端IP訪問次數(shù)

Elasticsearch 中添加 IK Analyzer分詞器后,在Kibana中檢索“中國科學(xué)技術(shù)大學(xué)”,得到較好的分詞結(jié)果,圖7高亮顯示了有實際意義的詞組.

傳統(tǒng)日志分析方案通常采用單機(jī)處理,它的資源利用率不高且可靠性較弱.傳統(tǒng)日志分析方案與本文設(shè)計方案的各項指標(biāo)對比見表4.

圖7 日志關(guān)鍵詞檢索結(jié)果

表4 傳統(tǒng)日志分析方案與本文設(shè)計方案對比

本系統(tǒng)還具備快速部署的優(yōu)點.傳統(tǒng)方式需要對新部署的服務(wù)器重新配置應(yīng)用的運行環(huán)境,而Docker容器部署方式只需要拷貝Dockerfile文件、構(gòu)建鏡像、運行容器,即可完成部署,效率遠(yuǎn)高于傳統(tǒng)部署方式.隨著部署節(jié)點不斷增多,Docker容器部署方式的優(yōu)勢更加明顯.

4 結(jié)語

本文設(shè)計了基于Docker的大規(guī)模日志采集和分析系統(tǒng),該系統(tǒng)結(jié)合了Fluentd高效數(shù)據(jù)采集工具、Kafka消息隊列、Elasticsearch分布式搜索引擎、Kibana數(shù)據(jù)分析和可視化平臺、Docker容器等開源技術(shù).本系統(tǒng)主要分為數(shù)據(jù)采集、數(shù)據(jù)緩存、數(shù)據(jù)轉(zhuǎn)發(fā)、數(shù)據(jù)存儲、數(shù)據(jù)檢索和展示五層.該系統(tǒng)實現(xiàn)日志分析的分層解耦,能夠?qū)崟r高效對大規(guī)模日志進(jìn)行處理分析,并以可視化方式展示.同時利用Docker虛擬化容器技術(shù)實現(xiàn)系統(tǒng)快速部署和版本控制,提高了運維效率.實驗結(jié)果分析表明,本文采用的技術(shù)路線和設(shè)計方法可行有效.下一步將結(jié)合Hadoop、Spark等其他大數(shù)據(jù)分析技術(shù)對日志進(jìn)行更深層次的挖掘,從而獲得更多有價值的信息.

1涂新莉,劉波,林偉偉.大數(shù)據(jù)研究綜述.計算機(jī)應(yīng)用研究,2014,31(6):1612–1616,1623.

2Suneetha KR,Krishnamoorthi R.Identifying user behavior by analyzing web server access log file.IJCSNS International Journal of Computer Science and Network Security,2009,9(4):327–332.

3Scribe logfile aggregation system described by facebook’s Jeff hammerbacher.https://github.com/facebookarchive/scribe.2008.

4Rabkin A,Katz RH.Chukwa:a system for reliable largescale log collection.Proc.the 24th International Conference on Large Installation System Administration.Berkeley,CA,USA.2010.1–15.

5趙龍,江榮安.基于Hive的海量搜索日志分析系統(tǒng)研究.計算機(jī)應(yīng)用研究,2013,30(11):3343–3345.

6Boettiger C.An introduction to Docker for reproducible research.ACM SIGOPS Operating Systems Review,2015,49(1):71–79.[doi:10.1145/2723872]

7Felter W,Ferreira A,Rajamony R,et al.An updated performance comparison of virtual machines and Linux containers.Proc.of 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS).Philadelphia,PA,USA.2015.171–172.

8Fluentd.http://docs.fluentd.org/articles/quickstart.

9Carlson JL.Redis in action.Shelter Island,NY:Manning Publications Co.,2013.

10Kreps J,Narkhede N,Rao J.Kafka:a distributed messaging system for log processing.Proc.of the NetDB’11.Athens,Greece.2011.1–7.

11Gormley C,Tong Z.Elasticsearch:the definitive guide.Sebastopol,CA:O’Reilly Media,Inc.,2015.

12朱潛,吳辰鈮,朱志良,等.Hadoop 云平臺下 Nutch 中文分詞的研究與實現(xiàn).小型微型計算機(jī)系統(tǒng),2013,34(12):2772–2776.[doi:10.3969/j.issn.1000-1220.2013.12.022]

Large-Scale Log Collection and Analysis System Based on Docker

LUO Dong-Feng1,2,LI Fang1,HAO Wang-Yang1,2,WU Zhong-Cheng11(High Magnetic Field Laboratory,Chinese Academy of Sciences,Hefei 230031,China)2(University of Science and Technology of China,Hefei 230026,China)

The traditional log analysis technology has low efficiency,simple function,poor scalability in practice in processing the large-scale log.To solve these problems,a large-scale log collection and analysis system based on Docker is designed.There are five layers including data collection,data cache,data forwarding,data storage,data retrieval and display in the system.And the system can take in any type of log files from different data sources,provide reliable data transmission through Kafka message queue,utilize Elasticsearch to realize distributed storage and retrieval of data,and analyze log by means of visualization.Meanwhile,the use of docker container technology can realize rapid deployment and version control of the system.The system has the characteristics of real-time,scalability,easy deployment and so on.The experimental results show that the system is feasible and effective with good practical value.

log collection and analysis; Docker; elasticsearch; open source; scalability; real time

羅東鋒,李芳,郝汪洋,吳仲城.基于Docker的大規(guī)模日志采集與分析系統(tǒng).計算機(jī)系統(tǒng)應(yīng)用,2017,26(10):82–88.http://www.c-sa.org.cn/1003-3254/5997.html

國家自然科學(xué)基金(61273323)

2017-01-13; 采用時間:2017-02-23