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

姚 攀，馬玉鵬，徐春香

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

0 引 言

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

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

1 相關(guān)工作

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

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

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

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

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

ELK技術(shù)在大數(shù)據(jù)系統(tǒng)[1]、電子商務(wù)平臺(tái)[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的日志分析平臺(tái)

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

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

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

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

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

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

(3)Packetbeat：收集網(wǎng)絡(luò)流數(shù)據(jù)，可以實(shí)時(shí)監(jiān)控系統(tǒng)應(yīng)用和服務(wù)，可以將延遲時(shí)間、錯(cuò)誤、響應(yīng)時(shí)間、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)存幾乎可以忽略不計(jì)。另外，Beats和Logstash之間支持SSL/TLS加密傳輸，客戶端和服務(wù)器雙向認(rèn)證，保證了通信安全。

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

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

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

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

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

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

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

(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]車(chē)輛號(hào)牌為空

對(duì)應(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":"車(chē)輛號(hào)牌為空。"

}

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

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

Elasticsearch集群中的節(jié)點(diǎn)一般有3種角色，在搭建完全分布式集群以前需要在配置文件中指定節(jié)點(diǎn)的角色，簡(jiǎ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)起到路由請(qǐng)求的作用，實(shí)際上可以看作負(fù)載均衡器，適用于高并發(fā)訪問(wèn)的業(yè)務(wù)場(chǎng)景。

表1 Elasticsearch和RDMS概念對(duì)比

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

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

2.4 日志可視化分析

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

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

3 Elasticsearch集群優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

3.3 查詢優(yōu)化

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

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

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

4 性能評(píng)估與可視化分析

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

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

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

按照2.3小節(jié)中設(shè)計(jì)的Elasticsearch集群拓?fù)浣Y(jié)構(gòu)，使用3臺(tái)CentOS服務(wù)器安裝部署了3節(jié)點(diǎn)集群。服務(wù)器的配置如下：操作系統(tǒng)為CentOS 6.5，六核2.10 GHz CPU，磁盤(pán)為非SSD普通磁盤(pán)，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，壓力測(cè)試工具為Apache JMeter 3.2。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

由以上分析可得結(jié)論：?jiǎn)嗡饕f(wàn)條日志量級(jí)下，集群對(duì)match查詢的響應(yīng)時(shí)間極快，而聚合分析的過(guò)程更為復(fù)雜，耗時(shí)更長(zhǎng)。

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

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

統(tǒng)計(jì)索引所占內(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)化百分比見(jiàn)表3，對(duì)比如圖4所示。從圖表中可以看出，內(nèi)存優(yōu)化百分比從6.7%到15.9%不等，段合并優(yōu)化效果十分明顯。

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

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

4.4 日志可視化分析

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

圖5 Kibana儀表盤(pán)

5 結(jié)束語(yǔ)

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