基于ELK的日志分析系統(tǒng)研究及應(yīng)用

姚 攀，馬玉鵬，徐春香

(1.中國科學(xué)院 新疆理化技術(shù)研究所，新疆 烏魯木齊 830011；2.新疆民族語音語言信息處理實(shí)驗(yàn)室，新疆 烏魯木齊 830011；3.中國科學(xué)院大學(xué)，北京 100049)

0 引 言

日志是系統(tǒng)運(yùn)維、故障診斷、性能分析的重要來源，對于任何系統(tǒng)而言都是極其重要的組成部分。隨著大數(shù)據(jù)時代的來臨，系統(tǒng)日志量也呈指數(shù)級增加。伴隨著日志格式復(fù)雜度的增加、日志規(guī)模的擴(kuò)大以及應(yīng)用節(jié)點(diǎn)的增多，傳統(tǒng)的日志分析手段耗時耗力、效率低下、無法勝任復(fù)雜事件處理[1,2]等缺點(diǎn)逐漸暴露出來。傳統(tǒng)的日志分析方法已經(jīng)不能滿足實(shí)時化的需求，實(shí)時化已經(jīng)成為當(dāng)今大數(shù)據(jù)技術(shù)的發(fā)展趨勢之一[3]。

隨著硬件成本的降低以及實(shí)時分析技術(shù)的發(fā)展成熟，在日志處理領(lǐng)域出現(xiàn)了以ELK(日志采集工具Logstash、分布式搜索引擎Elasticsearch、數(shù)據(jù)可視化分析平臺Kibana)為代表的實(shí)時日志分析平臺，使運(yùn)維人員從浩如煙海的日志信息中輕松準(zhǔn)確地監(jiān)控及維護(hù)所需關(guān)注的信息及實(shí)現(xiàn)日志統(tǒng)計分析成為了可能[4]。本文基于ELK技術(shù)棧，實(shí)現(xiàn)了能對海量日志進(jìn)行實(shí)時采集和檢索的分析監(jiān)控系統(tǒng)。

1 相關(guān)工作

國內(nèi)外很多大學(xué)和研究機(jī)構(gòu)都做了日志領(lǐng)域的相關(guān)研究，如加拿大麥吉爾大學(xué)信息學(xué)院、國防科學(xué)技術(shù)大學(xué)、中國科學(xué)院計算機(jī)網(wǎng)絡(luò)中心、浙江大學(xué)CAD&CG重點(diǎn)實(shí)驗(yàn)室等。

文獻(xiàn)[3]研究了大數(shù)據(jù)環(huán)境下分布式數(shù)據(jù)流處理系統(tǒng)的各個子系統(tǒng)，包括數(shù)據(jù)收集子系統(tǒng)、消息隊列管理子系統(tǒng)、流式數(shù)據(jù)處理子系統(tǒng)和數(shù)據(jù)存儲子系統(tǒng)，對4類子系統(tǒng)涉及的關(guān)鍵技術(shù)做了詳細(xì)介紹并從應(yīng)用角度做了比較。

文獻(xiàn)[5]系統(tǒng)地綜述了日志研究的進(jìn)展，從日志特征分析、日志故障診斷、日志分析3個大的方面對日志的研究領(lǐng)域、研究方法、研究方向和未來的挑戰(zhàn)做了總結(jié)，具有很強(qiáng)的指導(dǎo)意義。

文獻(xiàn)[6]介紹了LARGE系統(tǒng)中采用類MapReduce機(jī)制對大規(guī)模系統(tǒng)日志的日志模式提煉算法的優(yōu)化方法，指出了近年來對Elastic公司開發(fā)的ELK組合的研究和使用呈現(xiàn)顯著增長的趨勢，ELK作為實(shí)時數(shù)據(jù)分析框架對日志流處理有一定優(yōu)勢，對特定系統(tǒng)或環(huán)境的分析需求仍需其它輔助分析程序[6]。

文獻(xiàn)[7]使用Flume收集日志，使用插件為Hbase提供日志事件，使用Elasticsearch做日志搜索，提出了實(shí)時大數(shù)據(jù)日志搜索集成方案，有一定借鑒意義，但是日志的傳輸和存儲過于復(fù)雜。

ELK技術(shù)在大數(shù)據(jù)系統(tǒng)[1]、電子商務(wù)平臺[4]、天文系統(tǒng)[8]、電力系統(tǒng)[9]都有相關(guān)應(yīng)用，在系統(tǒng)監(jiān)控和數(shù)據(jù)分析方面有著良好的效果。本文在此基礎(chǔ)之上，在日志收集方面使用Beats取代Logstash，進(jìn)一步探索與總結(jié)Elasticsearch集群的優(yōu)化方法。

2 基于ELK的日志分析平臺

2.1 日志分析系統(tǒng)整體架構(gòu)

一個完整的日志分析系統(tǒng)主要包括日志采集系統(tǒng)、日志解析系統(tǒng)、日志存儲系統(tǒng)和可視化分析系統(tǒng)4部分。典型的ELK架構(gòu)中，Logstash作為日志收集器分布于多臺機(jī)器，把非結(jié)構(gòu)化日志按照規(guī)則解析然后輸出至Elasticsearch；Elasticsearch可以當(dāng)作一個具有全文檢索功能的NoSQL數(shù)據(jù)庫來使用，在日志處理這個業(yè)務(wù)場景中Elasticsearch作為存儲日志的中央系統(tǒng)；Kibana是數(shù)據(jù)分析與可視化分析組件，可以對Elasticsearch中的日志進(jìn)行高效的搜索、統(tǒng)計分析與可視化操作。由于Logstash既作為日志搜集器又作為解析器，會消耗較多的CPU和內(nèi)存資源，如果服務(wù)器計算資源不夠豐富，容易造成服務(wù)器性能下降甚至無法工作。為了解決了Logstash占用系統(tǒng)資源較高的問題，Elastic公司推出了輕量級的日志采集器Beats，在數(shù)據(jù)收集方面取代Logstash，引入Beats后的系統(tǒng)架構(gòu)如圖1所示。

圖1 ELK+Beats架構(gòu)

Beats是一系列采集器的總稱，對于不同的日志源和日志格式可以使用不同的Beats，目前Beats家族包括以下5個成員：

(1)Filebeat：輕量級的日志采集器，可用于收集文件數(shù)據(jù)。

(2)Metricbeat：5.0版本之前名為Topbeat，搜集系統(tǒng)、進(jìn)程和文件系統(tǒng)級別的CPU和內(nèi)存使用情況等數(shù)據(jù)。

(3)Packetbeat：收集網(wǎng)絡(luò)流數(shù)據(jù)，可以實(shí)時監(jiān)控系統(tǒng)應(yīng)用和服務(wù)，可以將延遲時間、錯誤、響應(yīng)時間、SLA性能等信息發(fā)送到Logstash或Elasticsearch。

(4)Winlogbeat：搜集Windows事件日志數(shù)據(jù)。

(5)Heartbeat：監(jiān)控服務(wù)器運(yùn)行狀態(tài)。

相比Logstash，Beats所占系統(tǒng)的CPU和內(nèi)存幾乎可以忽略不計。另外，Beats和Logstash之間支持SSL/TLS加密傳輸，客戶端和服務(wù)器雙向認(rèn)證，保證了通信安全。

2.2 日志實(shí)時收集系統(tǒng)

日志收集是日志分析處理的前提與基礎(chǔ)，很多應(yīng)用系統(tǒng)的日志都分布在不同的服務(wù)器上，把分散的日志匯總之后才能做后續(xù)的處理分析?，F(xiàn)階段的日志都是文件格式，使用Filebeat和Logstash構(gòu)建日志收集系統(tǒng)。

Filebeat是GO語言開發(fā)的輕量級日志采集器，在應(yīng)用服務(wù)器上以代理的形式安裝。當(dāng)Filebeat啟動時，它會啟動一個或者多個prospector監(jiān)控日志路徑或日志文件，每個日志文件會有一個對應(yīng)的harvester，harvester按行讀取日志內(nèi)容并轉(zhuǎn)發(fā)至后臺程序。Filebeat維護(hù)了一個記錄文件讀取信息的注冊文件，記錄每個harvester最后讀取位置的偏移量。

Logstash是分布式數(shù)據(jù)收集引擎，在日志處理中擔(dān)任搬運(yùn)工的角色，它支持動態(tài)的從各種數(shù)據(jù)源搜集數(shù)據(jù)，并對數(shù)據(jù)進(jìn)行過濾、分析、統(tǒng)一格式等操作，然后輸出到用戶指定的位置。事件流通過Logstash中的Input、Filter和Output插件處理和轉(zhuǎn)換，Input用于配置日志的輸入源，F(xiàn)ilter用來解析日志，Output指定日志的輸出去向[10]。

Grok是Logstash的一個正則解析插件，它能對日志流進(jìn)行解析，內(nèi)置了120多種的正則表達(dá)式庫，對日志解析時需要針對日志格式定義相應(yīng)的正則表達(dá)式。結(jié)合Grok提供的便利，總結(jié)出按行讀取文件格式日志的解析步驟：

(1)首先對日志進(jìn)行分析，明確每一個字段的含義，確定日志的切分規(guī)則，也就是一條日志切分成哪幾個字段，這些字段是以后做日志分析的關(guān)鍵，對原始日志的解讀和分析是非常關(guān)鍵的一步。

(2)根據(jù)步驟(1)的切分原則確定提取每一個字段的正則表達(dá)式，如果Grok中的正則庫滿足需求直接使用即可，否則采用自定義模式，兩者可以組合使用。

(3)在Grok Debugger調(diào)試工具中調(diào)試、驗(yàn)證解析日志的正則表達(dá)式是否正確。

以下是應(yīng)用系統(tǒng)中的一條半結(jié)構(gòu)化日志：

2017-03-16 00:00:01， 570 133382978[HandleConsu-mer.java:445:INFO]車輛號牌為空

對應(yīng)的Grok表達(dá)式如下：

%{TIMESTAMP_IS08601:time}s*%{NUMBER:bytes}[s*%{JAVAFILE:class}:%{NUMBER:lineNumber}s*:%{LOGLEVEL:level}s*]s*(?([sS]*))

格式化后的日志如下：

{

"time":"2017-03-16 00:00:01,570",

"bytes":"133382978",

"class":"HandleConsumer.java",

"lineNumber":"445",

"level":"INFO",

"info":"車輛號牌為空。"

}

2.3 日志存儲與搜索系統(tǒng)

Elasticsearch是一個建立在Lucene基礎(chǔ)之上的分布式搜索引擎，基于RESTful web接口，可用于全文搜索、結(jié)構(gòu)化搜索以及聚合分析，有著分布式、零配置、高可用、集群自動發(fā)現(xiàn)、索引自動分片、模式自由、近實(shí)時搜索等優(yōu)點(diǎn)。表1對比了Elasticsearch和關(guān)系型數(shù)據(jù)庫中的一些重要術(shù)語。

Elasticsearch集群中的節(jié)點(diǎn)一般有3種角色，在搭建完全分布式集群以前需要在配置文件中指定節(jié)點(diǎn)的角色，簡介如下：

Master節(jié)點(diǎn)：master節(jié)點(diǎn)主要負(fù)載元數(shù)據(jù)的處理，比如索引的新增、刪除、分片分配等，每當(dāng)元數(shù)據(jù)有更新，master節(jié)點(diǎn)負(fù)責(zé)同步到其它節(jié)點(diǎn)之上。

Data節(jié)點(diǎn)：data節(jié)點(diǎn)上保存了數(shù)據(jù)分片。它負(fù)責(zé)數(shù)據(jù)相關(guān)操作，比如分片的增刪改查以及搜索和整合操作。

Client節(jié)點(diǎn)：client節(jié)點(diǎn)起到路由請求的作用，實(shí)際上可以看作負(fù)載均衡器，適用于高并發(fā)訪問的業(yè)務(wù)場景。

表1 Elasticsearch和RDMS概念對比

綜合考慮現(xiàn)階段的日志量和服務(wù)器硬件配置，使用3臺CentOS服務(wù)器搭建了Elasticsearch集群，集群拓?fù)鋱D如圖2所示。

圖2 Elasticsearch集群拓?fù)浣Y(jié)構(gòu)

2.4 日志可視化分析

孟小峰教授明確指出：“可視化技術(shù)是數(shù)據(jù)分析與信息獲取的重要手段[11]?！睌?shù)據(jù)可視化是大數(shù)據(jù)的最后一公里，通過可視化可以將抽象的數(shù)據(jù)轉(zhuǎn)化為直觀的圖表，能夠有效的將要點(diǎn)信息展示給人們。

Kibana是一個開源日志分析及可視化平臺，使用它可以對存儲在Elasticsearch索引中的數(shù)據(jù)進(jìn)行高效的搜索、可視化、分析等各種操作。Kibana的愿景是讓海量數(shù)據(jù)更容易理解，通過瀏覽器的用戶界面可以創(chuàng)建各種高級圖表進(jìn)行數(shù)據(jù)分析和展示，它的儀表盤功能可以匯總多個單操作圖表，并且可以實(shí)時顯示查詢動態(tài)。

3 Elasticsearch集群優(yōu)化

Elasticsearch作為存儲和搜索日志的中央系統(tǒng)，向下對接日志采集系統(tǒng)，向上配合Kibana做可視化分析，優(yōu)化集群配置可以使其獲得更優(yōu)的性能。

3.1 硬件層面優(yōu)化配置

(1)合理選擇服務(wù)器。Elasticsearch的運(yùn)行對JDK版本、Linux內(nèi)核、最小內(nèi)存等都有一定的要求，在安裝部署集群之前需要選擇和Elasticsearch版本匹配的服務(wù)器配置，同時也要根據(jù)業(yè)務(wù)量做集群規(guī)劃。

(2)提高Linux系統(tǒng)應(yīng)用程序最大打開文件數(shù)。在啟動Elasticsearch集群以前，增大機(jī)器的最大文件數(shù)，可以避免數(shù)據(jù)導(dǎo)入高峰時期打開文件過多異常的發(fā)生。

(3)增大虛擬映射內(nèi)存。Elasticsearch寫入文檔時最終要使用Lucene構(gòu)建倒排索引，增大虛擬映射內(nèi)存可以加快索引速度。

3.2 數(shù)據(jù)導(dǎo)入性能優(yōu)化

(1)關(guān)閉_all字段。_all字段是把一個文檔的所有字段合并在一起的超級字段，在搜索字段不明確的情況下可以對_all進(jìn)行搜索，默認(rèn)是開啟的。如果沒有模糊搜索的需要，關(guān)閉_all字段可以縮小索引大小，提高導(dǎo)入性能。

(2)設(shè)置副本為0。如果副本不為0，Master節(jié)點(diǎn)需要把文檔復(fù)制到副本分片上，復(fù)制過程需要消耗系統(tǒng)資源，因此可以在數(shù)據(jù)導(dǎo)入階段設(shè)置副本為0，等數(shù)據(jù)導(dǎo)入完成以后再提高副本數(shù)。

(3)對不必要的字段不索引。Elasticsearch可以通過參數(shù)設(shè)置字段是否建索引，建索引需要分詞、解析、建倒排記錄表等一系列過程，可以根據(jù)業(yè)務(wù)需求對不必要的字段(比如需要精確匹配的地名)不索引。

(4)使用批量導(dǎo)入。文檔一條一條的導(dǎo)入會導(dǎo)致頻繁的磁盤讀寫，使用批量導(dǎo)入可以降低I/O消耗。

(5)適當(dāng)增大刷新間隔。索引數(shù)據(jù)過程中為了使數(shù)據(jù)盡快可搜索，Elasticsearch會不斷刷新創(chuàng)建新的段并打開它，默認(rèn)1s刷新1次，在數(shù)據(jù)導(dǎo)入期間可適當(dāng)增大刷新間隔，待數(shù)據(jù)導(dǎo)入完成以后再恢復(fù)至默認(rèn)設(shè)置。

3.3 查詢優(yōu)化

(1)使用路由。路由機(jī)制即是通過哈希算法，將具有相同哈希值的文檔放置到同一個主分片中，合理使用路由機(jī)制可以提高查詢性能。

(2)正確使用Query和Filter。Query和Filter都有查詢的功能，但是Query使用的是搜索機(jī)制，需要通過評分模型計算相關(guān)度，而Filter是過濾機(jī)制，只需要根據(jù)條件進(jìn)行過濾，無需計算相關(guān)度，因此Filter響應(yīng)時間更快。

(3)使用Optimize API合并段。Elasticsearch中每個分片有多個段，每個段都是一個完整的倒排索引，在查詢時Elasticsearch會把所有段的查詢結(jié)果匯總作為最終的查詢結(jié)果。當(dāng)索引的文檔不斷增多時段也會增多，查詢性能就會下降。Optimize API可以強(qiáng)制分片進(jìn)行段合并，把多個小的段合并成大的段(通常合并成一個段)，通過減少段的數(shù)量達(dá)到提高搜索性能的目的。在日志處理場景中，日志的存儲一般按天、周、月存入索引，而且日志一旦索引就不會再修改，索引只是可讀的，這種情況下把索引段設(shè)為1是非常有效的。

4 性能評估與可視化分析

4.1 實(shí)驗(yàn)數(shù)據(jù)

本實(shí)驗(yàn)使用服務(wù)器上2500萬條日志數(shù)據(jù)來完成，實(shí)驗(yàn)中把2500萬條日志分成500萬條、1000萬條、1500萬條、2000萬條、2500萬條5組。

4.2 實(shí)驗(yàn)環(huán)境

按照2.3小節(jié)中設(shè)計的Elasticsearch集群拓?fù)浣Y(jié)構(gòu)，使用3臺CentOS服務(wù)器安裝部署了3節(jié)點(diǎn)集群。服務(wù)器的配置如下：操作系統(tǒng)為CentOS 6.5，六核2.10 GHz CPU，磁盤為非SSD普通磁盤，Elasticsearch運(yùn)行內(nèi)存為16 G。實(shí)驗(yàn)使用的軟件版本信息如下：Elasticsearch版本為2.3.3，Logstash版本為2.4.0，Kibana版本為4.4.0，F(xiàn)ilebeat版本為1.3.1，壓力測試工具為Apache JMeter 3.2。

4.3 實(shí)驗(yàn)結(jié)果

為了測試集群的日志搜索響應(yīng)時間和集群優(yōu)化效果，設(shè)計了2組實(shí)驗(yàn)：

TEST1：測試不同量級不同查詢條件下日志搜索的響應(yīng)時間。

TEST2：測試段合并前后索引內(nèi)存的優(yōu)化效果。

TEST1中設(shè)置以下3個查詢條件進(jìn)行日志搜索和聚合分析測試：

Q1：match查詢統(tǒng)計文件的上傳數(shù)量

Q2：filter聚合統(tǒng)計日志級別為ERROR的日志數(shù)量

Q3：terms分桶統(tǒng)計各服務(wù)器的日志導(dǎo)入量

在Apache Jmeter中使用10組200個線程，模擬200個用戶同時并發(fā)訪問，循環(huán)測試10次之后取平均值，查詢響應(yīng)時間的統(tǒng)計結(jié)果見表2，折線圖如圖3所示。

表2 查詢響應(yīng)時間/ms

圖3 不同條件下查詢響應(yīng)時間

從表2中可以看出，Q1的響應(yīng)時間均在0.15 s以內(nèi)，響應(yīng)時間并沒有隨著日志數(shù)量的加倍而倍增，Q2和Q3的響應(yīng)時間明顯高于Q1。從圖3中可以看出，Q1的響應(yīng)時間增長率接近水平，Q2和Q3的響應(yīng)時間隨著日志量的增加呈現(xiàn)線性增長的趨勢。究其原因，Q1使用的是match查詢，查詢的是倒排索引，根據(jù)查詢關(guān)鍵詞找到倒排記錄表中的文檔ID集合，因此文檔數(shù)量的成倍增加并不會導(dǎo)致查詢時間的成倍增加。相比match查詢，聚合分析的步驟更為復(fù)雜，流程如下：

(1)為需要聚合的字段構(gòu)造Global Ordinals，耗時取決于索引段的多少以及字段的不同唯一值的數(shù)量。

(2)根據(jù)match查詢結(jié)果得到文檔ID集合，借助統(tǒng)計字段的doc values值得到統(tǒng)計字段的值集合。

(3)將統(tǒng)計字段映射到Global Ordinal構(gòu)造的分桶里并統(tǒng)計各分桶中值的個數(shù)。

(4)根據(jù)聚合設(shè)置的返回文檔數(shù)返回Top size的分桶數(shù)據(jù)。

由以上分析可得結(jié)論：單索引千萬條日志量級下，集群對match查詢的響應(yīng)時間極快，而聚合分析的過程更為復(fù)雜，耗時更長。

TEST2中分別統(tǒng)計段合并前后日志占用的內(nèi)存大小，段合并的命令如下：

curl XPOST "10.90.1.64:9200/test_500/_optimize?max_num_segments=1"

統(tǒng)計索引所占內(nèi)存的命令如下：

curl-s"http://10.90.1.64:9200/_cat/segments/test_500?v&h=shard,segment,size,size.memory"|awk‘{sum+=＄NF} END {print sum}’

段合并前后各索引所占的內(nèi)存情況、內(nèi)存優(yōu)化量和優(yōu)化百分比見表3，對比如圖4所示。從圖表中可以看出，內(nèi)存優(yōu)化百分比從6.7%到15.9%不等，段合并優(yōu)化效果十分明顯。

表3 段合并內(nèi)存統(tǒng)計/Mb

圖4 段合并前后索引內(nèi)存對比

4.4 日志可視化分析

在Kibana中可以生成多種圖表，如圖5所示，左到右由上而下依次為：HTTP狀態(tài)碼對應(yīng)的頁面比例圖、日志導(dǎo)入量時段圖、日志總條數(shù)、系統(tǒng)的UV統(tǒng)計(由于使用了代理UV數(shù)量較少)、客戶端瀏覽器代理比例圖、訪問頁面Top 10、各主機(jī)日志導(dǎo)入比例圖。

圖5 Kibana儀表盤

5 結(jié)束語

本文對ELK日志分析平臺進(jìn)行了研究及應(yīng)用，在各個應(yīng)用服務(wù)器上部署B(yǎng)eats家族中的Filebeat完成日志采集工作，探索了Logstash解析日志的規(guī)則與技巧，總結(jié)了優(yōu)化Elasticsearch分布式集群相關(guān)經(jīng)驗(yàn)，最后在Kibana中對日志做了聚合和可視化的分析。解決了日志采集、日志解析、日志存儲、日志檢索、日志可視化的問題，為系統(tǒng)維護(hù)和日志分析提供了有效的方法。