基于分布式平臺的實時網(wǎng)絡日志分析系統(tǒng)設計

何長鵬

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

0 引言

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

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

1 系統(tǒng)整體框架設計

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

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

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

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

2 功能模塊設計

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

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

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

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

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

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

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

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

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

2.3 實時日志分析模塊

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

Elasticsearch是一個分布式、高擴展、高實時的搜索與數(shù)據(jù)分析引擎。Kibana 是一個開源日志分析及可視化平臺，為Elasticsearch 提供日志分析的Web 接口，可使用它對日志進行高效的搜索、可視化、分析等各種操作。用戶通過瀏覽器可以創(chuàng)建各種高級圖表進行數(shù)據(jù)分析和展示，也可以使用儀表盤功能匯總多個單操作圖表，實時顯示查詢動態(tài)。基于以上分析，本文利用Elasticsearch強大的數(shù)據(jù)搜索功能和Kibana可視化分析功能，實現(xiàn)從HBase 數(shù)據(jù)庫索引日志文件，向用戶直接展示日志數(shù)據(jù)、告警信息和日志統(tǒng)計信息等。

3 實驗仿真

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

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

表1 集群部署情況

4 結(jié)語

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