何長鵬

（甘肅政法大學(xué)公安技術(shù)學(xué)院，甘肅蘭州 730070）

0 引言

現(xiàn)如今人們處在以“移動(dòng)互聯(lián)網(wǎng)”為代表的智能化時(shí)代，各種應(yīng)用程序時(shí)刻在不斷地產(chǎn)生數(shù)據(jù)。隨著網(wǎng)絡(luò)用戶數(shù)的增加，數(shù)據(jù)每天以幾何級的速度快速增長，PB級別的海量用戶數(shù)據(jù)不斷地被制造出來，同時(shí)產(chǎn)生大規(guī)模的網(wǎng)絡(luò)日志數(shù)據(jù)。日志文件分析對于大規(guī)模系統(tǒng)的開發(fā)、維護(hù)和性能調(diào)整很重要，是故障排除和問題診斷的重要來源［1］。企業(yè)業(yè)務(wù)對日志處理的實(shí)時(shí)性需求也逐漸提高，這給傳統(tǒng)的網(wǎng)絡(luò)日志分析方法帶來嚴(yán)峻的挑戰(zhàn)［2］。為了滿足企業(yè)網(wǎng)絡(luò)安全監(jiān)控以及公安機(jī)關(guān)對電子數(shù)據(jù)取證方面的需求，促使研究人員不斷地改進(jìn)技術(shù)，提供針對大規(guī)模的網(wǎng)絡(luò)日志實(shí)時(shí)分析解決方案。

雖然大規(guī)模網(wǎng)絡(luò)日志分析系統(tǒng)設(shè)計(jì)取得了一些成果［3-8］，但由于日志文件的數(shù)量和復(fù)雜性在不斷增加，日志實(shí)時(shí)分析仍然面臨著巨大的挑戰(zhàn)。通常日志文件分散在多臺設(shè)備或者服務(wù)器上，日志文件不僅數(shù)據(jù)海量，且不同設(shè)備的日志文件存在優(yōu)先次序不一致、格式不統(tǒng)一、存儲(chǔ)時(shí)間比較短、不同種類的日志間相互聯(lián)系、處理時(shí)延較長等諸多問題［5］，使得日志的深度分析變得困難。因此，本文將從數(shù)據(jù)來源分類出發(fā)，借助分布式平臺Hadoop 在處理大數(shù)據(jù)方面的優(yōu)勢，設(shè)計(jì)實(shí)現(xiàn)了一種基于分布式平臺的實(shí)時(shí)網(wǎng)絡(luò)日志分析系統(tǒng)。根據(jù)不同主題把日志流進(jìn)行分組，日志文件實(shí)現(xiàn)分級優(yōu)化存儲(chǔ)機(jī)制，高效的搜索、可視化，集群實(shí)現(xiàn)負(fù)載均衡。

1 系統(tǒng)整體框架設(shè)計(jì)

在信息系統(tǒng)運(yùn)維中，工程師需要實(shí)時(shí)分析包括應(yīng)用負(fù)載、網(wǎng)絡(luò)流量、磁盤I/O等系統(tǒng)日志數(shù)據(jù)，來保障信息系統(tǒng)正常工作。一方面在企業(yè)級應(yīng)用系統(tǒng)中，日志系統(tǒng)本質(zhì)上起到輔助性的作用，設(shè)計(jì)時(shí)應(yīng)考慮盡量減少其系統(tǒng)開銷，提高效率和吞吐量，還要滿足跨平臺移植性和擴(kuò)展性；另一方面，日志系統(tǒng)要求服務(wù)運(yùn)行平穩(wěn)，服務(wù)集群具備高并發(fā)處理能力，滿足實(shí)時(shí)分析性能要求。因此，構(gòu)建的日志系統(tǒng)應(yīng)具有以下特征：（1）系統(tǒng)的低耦合性；（2）支持實(shí)時(shí)在線分析；（3）具有高可擴(kuò)展性。

基于上述設(shè)計(jì)原則，本文選擇主流的分布式的數(shù)據(jù)存儲(chǔ)和處理平臺Hadoop。Hadoop系統(tǒng)為用戶提供了一個(gè)海量數(shù)據(jù)分布式存儲(chǔ)和計(jì)算的框架，可以部署在廉價(jià)的計(jì)算機(jī)集群上，能夠滿足高并發(fā)性能要求。為了降低系統(tǒng)復(fù)雜性，優(yōu)先采用模塊化設(shè)計(jì)方法，將系統(tǒng)整體框架劃分三大組成部分：多源異構(gòu)日志數(shù)據(jù)收集模塊、日志分發(fā)存儲(chǔ)模塊、日志分析模塊以及可視化表示，如圖1所示。

圖1 實(shí)時(shí)日志分析系統(tǒng)框架

系統(tǒng)的三大組成部分之間可實(shí)現(xiàn)無縫銜接，具有分布式、高擴(kuò)展性、高可靠性、實(shí)時(shí)性等特點(diǎn)。日志數(shù)據(jù)采集層和日志數(shù)據(jù)匯集層協(xié)同設(shè)計(jì)，有效地降低了日志數(shù)據(jù)給服務(wù)器集群帶來的并發(fā)請求，并提高了服務(wù)器集群的高并發(fā)處理能力，保證了服務(wù)的穩(wěn)定運(yùn)行。

2 功能模塊設(shè)計(jì)

文獻(xiàn)［9］利用Chukwa 解決日志文件系統(tǒng)在數(shù)據(jù)處理階段耦合度高的問題，提高了日志處理的靈活性和擴(kuò)展性，但是在實(shí)時(shí)性方面Chukwa 對數(shù)據(jù)的敏感性較低，處理的數(shù)據(jù)是分鐘級別的，不能滿足海量數(shù)據(jù)的毫秒級高速處理。消息中間件Kafka 是一個(gè)高性能、高擴(kuò)張性的分布式海量日志采集、聚合和傳輸?shù)南到y(tǒng)，可以將日志數(shù)據(jù)持久化到硬盤，防止數(shù)據(jù)的丟失。因此，本文采用Kafka 集群構(gòu)建日志文件系統(tǒng)，首先數(shù)據(jù)采集模塊使用Beats 工具集將采集的日志數(shù)據(jù)發(fā)送給Kafka，然后Kafka 根據(jù)不同的主題（Topic）把日志流進(jìn)行分組，發(fā)布消息到訂閱模塊：HDFS文件系統(tǒng)和HBase數(shù)據(jù)庫。離線分析日志數(shù)據(jù)直接存儲(chǔ)在HDFS文件系統(tǒng)中，而實(shí)時(shí)處理數(shù)據(jù)則使用Fluentd 工具接收并存儲(chǔ)到HBase 數(shù)據(jù)庫中。最后利用Kibana 對存儲(chǔ)在索引中的數(shù)據(jù)進(jìn)行高效的搜索、可視化、分析等操作［7］。

2.1 日志數(shù)據(jù)收集模塊

日志服務(wù)對于應(yīng)用業(yè)務(wù)而言僅僅起到保障作用，要求實(shí)現(xiàn)快速、輕量的數(shù)據(jù)采集與傳輸，不應(yīng)占用服務(wù)器太多資源。Beats 屬于輕量級數(shù)據(jù)采集工具集，提供多種類型工具。其中，TopBeat 負(fù)責(zé)監(jiān)控資源；Metricbeat 收集系統(tǒng)資源信息，例如CPU、內(nèi)存、磁盤等信息；Packetbeat 收集網(wǎng)絡(luò)數(shù)據(jù)；Filebeat 負(fù)責(zé)日志文件的采集和傳輸，它能夠保持每個(gè)文件的狀態(tài)，并且頻繁地把文件狀態(tài)從注冊表更新到磁盤。FileBeat還具有占用內(nèi)存較低、性價(jià)比高、配置簡單等特點(diǎn)［10］，因此本文選擇FileBeat 工具采集各節(jié)點(diǎn)日志文件，對日志文件過濾、修剪之后，將日志文件發(fā)送到Kafka中，這樣可以縮短數(shù)據(jù)傳輸時(shí)間，提高傳輸效率。

日志文件系統(tǒng)支持 uuid、pid、timest、arvo、log4j、syslog 和http post 等類型，用戶也可以自定義日志類型文件。由于不同設(shè)備和應(yīng)用產(chǎn)生的日志文件格式不同，位置不同，需要統(tǒng)一日志收集規(guī)則、目錄和輸出方式［10］。例如，Web日志文件主要由不同類型的設(shè)備和服務(wù)器的日志構(gòu)成，但這些設(shè)備和服務(wù)器沒有統(tǒng)一的日志標(biāo)準(zhǔn)和格式，導(dǎo)致日志文件可讀性較差，有必要對不同類型的日志需要轉(zhuǎn)換為統(tǒng)一的方式處理。Fluentd 工具將所有日志看作JSON 格式的數(shù)據(jù)，并且用正則表達(dá)式去匹配日志。因此，本文將Fluentd 工具集成在日志收集模塊，來解決日志文件格式不統(tǒng)一的問題。

大型網(wǎng)絡(luò)當(dāng)中，日志文件規(guī)模較大，日志系統(tǒng)長期存儲(chǔ)的數(shù)據(jù)量可達(dá)到PB 級別，但大部分情況分析處理的更多是規(guī)模較小的日志文件。如果每項(xiàng)業(yè)務(wù)都要處理大規(guī)模的數(shù)據(jù)，必然耗時(shí)，且處理效率很低。在日志文件系統(tǒng)中用戶往往只對特定時(shí)間段、特定日志源的數(shù)據(jù)感興趣。本文利用文獻(xiàn)［11］中的文件分級歸檔管理機(jī)制，對數(shù)據(jù)文件進(jìn)行有效的分隔和合理的組織。根據(jù)文件大小和時(shí)間劃分不同的分級指標(biāo)，并為每一級設(shè)定最大歸檔閾值。這樣形成日志數(shù)據(jù)的倒金字塔存儲(chǔ)結(jié)構(gòu)，并且隨著日志數(shù)據(jù)的增大，文件數(shù)量不會(huì)呈現(xiàn)顯著的增長態(tài)勢，保持相對穩(wěn)定。

2.2 日志文件分發(fā)模塊

Kafka是一個(gè)分布式的、可分區(qū)的、可復(fù)制的基于Zookeeper 協(xié)調(diào)的分布式消息系統(tǒng)，可以實(shí)時(shí)處理大量數(shù)據(jù)以滿足各種需求場景。Kafka成功地實(shí)現(xiàn)了生產(chǎn)者（Producer）/消費(fèi)者（Consumer）模式，通過Hadoop并行加載機(jī)制統(tǒng)一了在線和離線消息的處理。本文選擇Kafka 作為日志系統(tǒng)消息發(fā)布訂閱模塊。中間層的Kafka Cluster 存儲(chǔ)消息，它是由多個(gè)Server 組成的集群。為了實(shí)現(xiàn)負(fù)載均衡，Kafka 將所有消息組織成多個(gè)主題（Topic）的形式存儲(chǔ)，而每個(gè)Topic又拆分成多個(gè)Partition，每個(gè)Partition 又由一個(gè)一個(gè)消息組成。每個(gè)消息都被標(biāo)識了一個(gè)遞增序列號代表其進(jìn)來的先后順序，并按順序存儲(chǔ)在Partition 中。一旦有新的關(guān)于某個(gè)Topic 的消息，Broker 會(huì)傳遞給訂閱它的所有消費(fèi)者。日志數(shù)據(jù)收集模塊采集到日志數(shù)據(jù)后向訂閱Topic 的消費(fèi)者發(fā)布消息，消費(fèi)者分別根據(jù)其主題將離線數(shù)據(jù)存儲(chǔ)在HDFS文件系統(tǒng)，將實(shí)時(shí)在線分析數(shù)據(jù)存儲(chǔ)在HBase數(shù)據(jù)庫當(dāng)中。

Kafka主要實(shí)現(xiàn)的是順序存儲(chǔ)，它通過Topic和消息隊(duì)列的機(jī)制，實(shí)現(xiàn)了數(shù)據(jù)快速存儲(chǔ)。如果數(shù)據(jù)采集模塊將所有的數(shù)據(jù)都寫入Kafka，會(huì)導(dǎo)致Topic 過多，引發(fā)磁盤競爭，進(jìn)而影響集群的性能。因此，利用Fluentd工具將日志文件根據(jù)time_slice_format進(jìn)行分割，并且在路徑中加入時(shí)間，從而可以根據(jù)路徑篩選出不同的日志，避免大量的日志產(chǎn)生干擾。

Hadoop 系統(tǒng)主要由分布式文件系統(tǒng)HDFS（Hadoop Distributed File System）、MapReduce 計(jì)算模型以及HBase 等組成。文件系統(tǒng)HDFS 和計(jì)算模型MapReduce，使用戶能充分利用集群的大容量空間存儲(chǔ)海量數(shù)據(jù)和集群高速計(jì)算能力開發(fā)分布式的應(yīng)用程序，實(shí)現(xiàn)海量數(shù)據(jù)的毫秒級高速處理［12］。通常完整的日志分析系統(tǒng)支持離線分析和實(shí)時(shí)在線分析功能。本文利用HDFSSink 將離線日志數(shù)據(jù)寫入HDFS中，HDFSSink 的優(yōu)勢是可以創(chuàng)建 Text 和 Sequence 格式文件，并對文件進(jìn)行壓縮處理。HDFSSink 支持基于時(shí)間、數(shù)量大小、事件數(shù)量的文件周期性滾動(dòng)，并通過 Event Hearder 屬性 TimeStamp 或 Host 來分割數(shù)據(jù)。將實(shí)時(shí)在線分析數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫HBase 中。由于HBase是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫，利用MapReduce 來處理海量數(shù)據(jù)，利用Zookeeper 作為其協(xié)同服務(wù)。

2.3 實(shí)時(shí)日志分析模塊

日志分析模塊收到特定主題的日志數(shù)據(jù)后進(jìn)行數(shù)據(jù)分析。存儲(chǔ)在HBase 中的日志數(shù)據(jù)處理以后可用于決策分析、預(yù)測分析、數(shù)據(jù)檢索及可視化［13］。常用的日志分析方法有關(guān)聯(lián)分析、序列分析、聚類分析等。在實(shí)際應(yīng)用中，日志分析場景是針對具體業(yè)務(wù)來進(jìn)行分析，分析的內(nèi)容包括用戶行為、應(yīng)用性能監(jiān)控、系統(tǒng)設(shè)備性能監(jiān)控、IoT 設(shè)備數(shù)據(jù)分析和監(jiān)控、安全、審計(jì)和監(jiān)控、異常探測和歸因分析等。本文設(shè)計(jì)的實(shí)時(shí)日志分析系統(tǒng)是為了滿足企業(yè)網(wǎng)絡(luò)安全監(jiān)控以及電子數(shù)據(jù)取證方面的需求，因此系統(tǒng)分析的主要目標(biāo)是檢測異常情況、追溯異常情況源頭、監(jiān)控異常指標(biāo)和定位系統(tǒng)問題等。

Elasticsearch是一個(gè)分布式、高擴(kuò)展、高實(shí)時(shí)的搜索與數(shù)據(jù)分析引擎。Kibana 是一個(gè)開源日志分析及可視化平臺，為Elasticsearch 提供日志分析的Web 接口，可使用它對日志進(jìn)行高效的搜索、可視化、分析等各種操作。用戶通過瀏覽器可以創(chuàng)建各種高級圖表進(jìn)行數(shù)據(jù)分析和展示，也可以使用儀表盤功能匯總多個(gè)單操作圖表，實(shí)時(shí)顯示查詢動(dòng)態(tài)?；谝陨戏治觯疚睦肊lasticsearch強(qiáng)大的數(shù)據(jù)搜索功能和Kibana可視化分析功能，實(shí)現(xiàn)從HBase 數(shù)據(jù)庫索引日志文件，向用戶直接展示日志數(shù)據(jù)、告警信息和日志統(tǒng)計(jì)信息等。

3 實(shí)驗(yàn)仿真

本文將使用VMware虛擬機(jī)搭建分布式集群實(shí)驗(yàn)環(huán)境，在2臺PC服務(wù)器上總共虛擬化4臺計(jì)算機(jī)組成群組，每臺計(jì)算機(jī)配置2個(gè)虛擬內(nèi)核，2 GB內(nèi)存，50 G磁盤存儲(chǔ)空間。操作系統(tǒng)為CentOS，根據(jù)表1所示安裝部署Hadoop、HBase、Kafka、Elasticsearch 和Kibana。按照默認(rèn)配置，NameNode 節(jié)點(diǎn)和JobTracker 部署在同一個(gè)節(jié)點(diǎn)上，其余每個(gè)節(jié)點(diǎn)上都部署為DataNode和TaskTracker。

系統(tǒng)測試采集的數(shù)據(jù)源來自某單位信息中心管理的Web 服務(wù)器、防火墻以及數(shù)據(jù)平臺上運(yùn)行的應(yīng)用系統(tǒng)的日志文件。其中Web 日志文件為文本文件記錄日志，將其流式數(shù)據(jù)保存為CSV類型文件。采集的日志數(shù)據(jù)根據(jù)設(shè)定的規(guī)則，進(jìn)行分級歸檔管理。以Web日志文件為分析對象，系統(tǒng)實(shí)時(shí)統(tǒng)計(jì)了用戶在網(wǎng)站上的頁面瀏覽量PV、獨(dú)立訪客UV、查詢和IP 地址等信息。

表1 集群部署情況

4 結(jié)語

伴隨著各種應(yīng)用軟件的普及，系統(tǒng)日志量呈現(xiàn)指數(shù)增長態(tài)勢，大規(guī)模的網(wǎng)絡(luò)日志數(shù)據(jù)需要進(jìn)行實(shí)時(shí)分析，但是日志文件存在數(shù)據(jù)格式、存儲(chǔ)方式不統(tǒng)一和數(shù)據(jù)分析流程復(fù)雜等缺點(diǎn)，導(dǎo)致實(shí)時(shí)網(wǎng)絡(luò)日志分析系統(tǒng)設(shè)計(jì)面臨諸多困難，系統(tǒng)復(fù)雜性較高。因此，本文采用模塊化的設(shè)計(jì)思想，將日志數(shù)據(jù)采集模塊、傳輸模塊與分析模塊分離，降低系統(tǒng)的耦合性。設(shè)計(jì)的日志數(shù)據(jù)收集模塊具有高并發(fā)、低時(shí)延的數(shù)據(jù)接入能力。利用文件分級歸檔管理機(jī)制可以對日志數(shù)據(jù)文件進(jìn)行優(yōu)化存儲(chǔ)，避免對Kafka 集群產(chǎn)生干擾，實(shí)現(xiàn)了負(fù)載均衡。通過將Fluentd工具集成在日志收集模塊，來解決日志文件格式不統(tǒng)一的問題。在可視化分析方面，利用Elasticsearch 和Kibana 實(shí)現(xiàn)了日志文件高效的搜索、可視化分析。從實(shí)驗(yàn)仿真的結(jié)果來看，本文所做的一些針對性的開發(fā)工作，可以縮短數(shù)據(jù)處理時(shí)延，提升服務(wù)集群高并發(fā)處理能力，滿足日志實(shí)時(shí)分析性能要求。