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

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

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

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

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

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 Docker工作流程圖

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

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

表1 Logstash 與 Fluentd 對(duì)比

基于可靠性和性能的考慮,本系統(tǒng)采用Fluentd實(shí)現(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ù)緩存層.該緩存層采用消息隊(duì)列的技術(shù)實(shí)現(xiàn),提高了系統(tǒng)的性能和可靠性.目前提供消息隊(duì)列服務(wù)的工具,主流的有 Redis 和 Kafka.Redis[9]是一個(gè)開源、高性能、基于內(nèi)存的鍵值對(duì)數(shù)據(jù)庫.它支持?jǐn)?shù)據(jù)的持久化和訂閱發(fā)布機(jī)制等高級(jí)特性.Kafka[10]是一種開源分布式發(fā)布訂閱消息系統(tǒng),具有高性能、高吞吐率、水平擴(kuò)展等特性.Kafka支持?jǐn)?shù)據(jù)離線處理和實(shí)時(shí)處理.本文選用Kafka消息隊(duì)列實(shí)現(xiàn)數(shù)據(jù)緩存層,因?yàn)镵afka提供消息持久化能力和容錯(cuò)性保證,在可靠性方面優(yōu)于Redis.Redis不保存已發(fā)送出去的消息,而 Kafka 可保存被消費(fèi)的消息的副本.此外,Kafka在處理海量日志方面更具優(yōu)勢(shì),Kafka利用磁盤存儲(chǔ)消息隊(duì)列的數(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ù)框架)實(shí)現(xiàn)Kafka各組件的服務(wù)協(xié)調(diào).Kafka發(fā)布訂閱的對(duì)象是話題(Topic),一個(gè)話題就是一類消息,Kafka通過從物理上劃分一個(gè)或多個(gè)分區(qū)(Partition)實(shí)現(xiàn)對(duì)話題的管理.Kafka實(shí)現(xiàn)了一個(gè)分區(qū)內(nèi)消息的有序性,但不能保證不同分區(qū)之間的消息有序.Kafka為同一數(shù)據(jù)源的所有日志創(chuàng)建一個(gè)話題.本系統(tǒng)為保證一個(gè)話題中所有消息的有序性,將該話題的分區(qū)數(shù)設(shè)置為一個(gè).發(fā)送消息到話題的一方稱為生產(chǎn)者(Producer).數(shù)據(jù)采集層就是消息隊(duì)列的消息生產(chǎn)者.而消費(fèi)者(Consumer)是訂閱話題消費(fèi)消息的一方.若話題中只有一個(gè)分區(qū),消費(fèi)者消費(fèi)該話題中消息的順序與該分區(qū)中消息先后順序一致.一個(gè)Kafka集群由一個(gè)或多個(gè)代理(Broker)服務(wù)器組成.Kafka的容錯(cuò)性是通過副本(Replica)機(jī)制實(shí)現(xiàn).Kafka允許用戶為每一個(gè)話題設(shè)置副本數(shù)量.副本是以分區(qū)為單位創(chuàng)建的.每個(gè)分區(qū)可以有一個(gè)或多個(gè)副本,每個(gè)副本保存在不同的代理上.若分區(qū)只有一個(gè)副本,則該副本就是領(lǐng)導(dǎo)者(leader),負(fù)責(zé)處理該分區(qū)的讀寫請(qǐng)求.若分區(qū)中有多個(gè)副本,則其中一個(gè)副本會(huì)被選舉為領(lǐng)導(dǎo)者,其他的副本則充當(dāng)跟隨者(follower)的角色.跟隨者會(huì)被動(dòng)去復(fù)制領(lǐng)導(dǎo)者上的數(shù)據(jù).當(dāng)領(lǐng)導(dǎo)者發(fā)生故障時(shí),會(huì)從這些跟隨者中選舉新的領(lǐng)導(dǎo)者.

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

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

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

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

圖3 Nginx 訪問日志

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

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

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

表2 Elasticsearch 和 Rational Database 對(duì)比

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

圖4 curl命令刪除一條文檔

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

當(dāng)集群需要存儲(chǔ)超出單個(gè)機(jī)器容量的數(shù)據(jù)時(shí),Elasticsearch會(huì)自動(dòng)將數(shù)據(jù)分別發(fā)送至多個(gè)存儲(chǔ)Lucene索引的機(jī)器上,這些Lucene索引稱為分片(Shard)索引.同時(shí)Elasticsearch通過副本(Replica)機(jī)制對(duì)分片進(jìn)行數(shù)據(jù)冗余,保證了集群的高可用.另外,Elasticsearch 支持插件機(jī)制,包含豐富且功能強(qiáng)大的插件.在分析含有中文內(nèi)容的日志時(shí),需要對(duì)中文檢索,而Elasticsearch內(nèi)置的標(biāo)準(zhǔn)分析器對(duì)中文分詞支持相對(duì)較弱.它在處理分詞時(shí),將中文的每一個(gè)漢字作為一個(gè)詞(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ù)存儲(chǔ)層中所有日志信息提供統(tǒng)一的查詢?nèi)肟?并可對(duì)日志進(jìn)行統(tǒng)計(jì)分析以可視化形式呈現(xiàn)結(jié)果.日志可視化將復(fù)雜和抽象的日志信息轉(zhuǎn)成圖表形式,使得用戶更容易理解日志之間的聯(lián)系和變化情況,便于用戶更好地做出決策.Kibana和Grafana都支持Elasticsearch數(shù)據(jù)可視化展示.Grafana是開源的可視化測(cè)量數(shù)據(jù)的工具,但對(duì)Elasticsearch數(shù)據(jù)檢索支持較弱.而Kibana是基于Apache License2.0開源協(xié)議,使用HTML語言和JavaScript編寫,可提供數(shù)據(jù)分析和可視化的Web前端應(yīng)用.它可以對(duì)Elasticsearch中的數(shù)據(jù)進(jìn)行搜索、分析和以統(tǒng)計(jì)圖表的方式展示結(jié)果.Kibana的查詢語法是基于Lucene的查詢語法,通過布爾運(yùn)算符、通配符和字段篩選進(jìn)行模式匹配搜索.用戶可選擇對(duì)查詢的結(jié)果進(jìn)行保存,方便以后再次查看.Kibana可以實(shí)時(shí)查看數(shù)據(jù)存儲(chǔ)層中最新存儲(chǔ)的日志信息.

3 實(shí)驗(yàn)測(cè)試及結(jié)果分析

本文重點(diǎn)驗(yàn)證系統(tǒng)整體的有效性以及Fluentd的數(shù)據(jù)采集效率.通過部署在同一局域網(wǎng)的9臺(tái)PC機(jī)搭建集群進(jìn)行測(cè)試.每臺(tái)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為本次實(shí)驗(yàn)系統(tǒng)部署架構(gòu),集群各個(gè)節(jié)點(diǎn)的配置及其功能描述如表3所示.實(shí)驗(yàn)數(shù)據(jù)集為模擬Nginx日志和Tomcat日志,實(shí)驗(yàn)時(shí)不斷地往被收集的日志文件中寫日志.

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

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

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

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

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

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

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

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

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

4 結(jié)語

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

1涂新莉,劉波,林偉偉.大數(shù)據(jù)研究綜述.計(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ì)算機(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 云平臺(tái)下 Nutch 中文分詞的研究與實(shí)現(xiàn).小型微型計(jì)算機(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ì)算機(jī)系統(tǒng)應(yīng)用,2017,26(10):82–88.http://www.c-sa.org.cn/1003-3254/5997.html

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

2017-01-13; 采用時(shí)間:2017-02-23