劉磊 孫路強 周利霞 許賀

摘要??? 本文基于Syslog的網(wǎng)絡(luò)日志管理平臺對海量日志進行收集，并通過模式匹配的方法對日志進行了分析，形成了日志分析告警，有效對設(shè)備和服務(wù)運行狀態(tài)進行監(jiān)控，在實際應(yīng)用中很好的解決了暴力破解發(fā)現(xiàn)，異常操作感知等問題。

【關(guān)鍵詞】Syslog 模式匹配 日志分析 告警 監(jiān)控

Syslog是一種工業(yè)標(biāo)準(zhǔn)的協(xié)議，用來記錄設(shè)備的運行日志，在Linux系統(tǒng)、路由器、交換機等網(wǎng)絡(luò)設(shè)備中日志記錄了系統(tǒng)中發(fā)生的大小事件。運維人員通過審計日志記錄可以隨時掌握系統(tǒng)和應(yīng)用程序的狀態(tài)。目前存在RFC3164和RFC5424兩個規(guī)范，文章主要應(yīng)用RFC3164這個規(guī)范，其中描述了BSDSyslog協(xié)議，這個協(xié)議不是強制性的，很多設(shè)備并不完全遵守這個規(guī)范。實際運維中發(fā)現(xiàn)不同設(shè)備日志格式是不同的，協(xié)議中定義的嚴(yán)重性并不能完全符合運維需要，這就需要根據(jù)系統(tǒng)特征定義符合實際應(yīng)用的規(guī)則對日志進行處理。

1 RFC3164 Syslog協(xié)議

RFC3164規(guī)范中Syslog日志信息發(fā)送使用UDP協(xié)議的514端口，信息長度不能大于1024字節(jié)，格式如圖1所示由PRI、HEADER、MSG三部分組成，PRI由帶尖括號的一個數(shù)字構(gòu)成，這個數(shù)字包含了日志的程序模塊（Facility）、嚴(yán)重性（Severity）信息，由Facility乘以8加上Severity得來。Facility如表1所示，Severity如表2所示。HEADER部分包括兩個字段，Time和Name，Time緊跟在PRI后面中間沒有空格，格式是“mm dd hh：mm：ss”，不包括年份。“日”的數(shù)字如果是1～9，前面會補一個空格，“小時”、“分”、“秒”在前面補“0”。HEADER部分后面跟一個空格，之后是MSG部分。MSG部分有兩個部分TAG和Content。其中TAG部分是可選的，TAG后面用一個冒號隔開Content部分，這部分的內(nèi)容是應(yīng)用程序自定義的。一條典型的日志信息如下所示：

<78>Dec 4 17：30：01 nagios /usr/sbin/ cron[5545]： （cactiuser） CMD （/usr/bin/php5 /srv/ www/htdocs/cacti/poller.php > /dev/null 2>&1）

2日志收集系統(tǒng)實現(xiàn)

2.1 服務(wù)器收集端配置

為了更好的對系統(tǒng)日志進行分析，根據(jù)RFC3164規(guī)范編寫了日志收集系統(tǒng)，在收集系統(tǒng)中定義了設(shè)備編號、嚴(yán)重級別、日志來源、接收字節(jié)大小，綁定IPv4網(wǎng)絡(luò)協(xié)議套接字、UPD接口類型，通過514端口接收數(shù)據(jù)包，對接收的數(shù)據(jù)包數(shù)據(jù)進行分離，分離出設(shè)備名稱、設(shè)備地址、發(fā)生時間、日志來源、日志等級、日志內(nèi)容等信息，插入到Mysql數(shù)據(jù)庫，實現(xiàn)了日志信息的集中收集，為了提高檢索效率，對每一臺設(shè)備建立了單獨的數(shù)據(jù)表。

2.2 客戶端系統(tǒng)配置

（1）在suse linux中一般使用syslog-ng，在系統(tǒng)的/etc/syslog-ng下，配置syslog-ng.conf，定義日志來源source、日志目標(biāo)destination、使用端口port，通過發(fā)送命令log{source（my_log）;destination（center_log_server）;};發(fā)送到日志收集端。

（2）在centoslinux中，一般使用rsyslog，通過/etc/rsyslog.conf進行配置，通過命令*.*@remote-host：514進行配置，通過UDP514端口發(fā)送到日志收集端。

（3）在h3c交換機中，通過info-center loghost IP port 514命令發(fā)送到日志收集端。

日志收集實現(xiàn)：日志服務(wù)器實現(xiàn)了路由器、防火墻、DNS、交換機、FTP服務(wù)、WEB服務(wù)、NTP服務(wù)、Oracle服務(wù)、Mysql服務(wù)等日志信息的收集，如圖2所示，Mysql數(shù)據(jù)庫中匯集的日志信息如圖3所示。

通過日志收集發(fā)現(xiàn)，系統(tǒng)定義的日志事件嚴(yán)重等級和需要的告警并不是完全匹配的，發(fā)現(xiàn)在已知系統(tǒng)中日志格式是相似的，對應(yīng)的異常是可知的，當(dāng)未引入新的進程或未發(fā)生新的異常時日志種類是有限的。根據(jù)日志有限的特性可以應(yīng)用統(tǒng)計規(guī)則對運行日志進行精確分類，標(biāo)識出所有已知的日志，構(gòu)建日志白名單規(guī)則，利用白名單進行日志告警。部分告警規(guī)則如表3所示。

2.3 日志統(tǒng)計告警實現(xiàn)

通過告警規(guī)則進行字符串匹配和分類，在日志數(shù)量相當(dāng)龐大時，實現(xiàn)逐條告警也是不可取的。對最近10分鐘內(nèi)接收的日志進行分析，對特定日志類型或某類日志達到一定數(shù)量進行告警并對運維人員發(fā)送信息。如圖4所示。

3 日志管理中需要解決的問題

（1）日志信息采集系統(tǒng)運行半年來個別系統(tǒng)日志信息達到25G，對數(shù)據(jù)庫性能造成很大影響，分析發(fā)現(xiàn)很多信息與系統(tǒng)運行無關(guān)，如何剔除這些無關(guān)信息是以后需要解決的重點。

（2）隨著時間的推移，日志信息量不斷增加，對海量日志數(shù)據(jù)進行查詢時，Mysql數(shù)據(jù)庫的性能瓶頸問題顯現(xiàn)，可以考慮使用非關(guān)系型數(shù)據(jù)庫或者混合型數(shù)據(jù)庫，解決海量數(shù)據(jù)下傳統(tǒng)數(shù)據(jù)庫性能上的瓶頸問題。

（3）本文的告警規(guī)則是在統(tǒng)計的基礎(chǔ)通過人工篩選的方法實現(xiàn)的，這種方法只適用于小型數(shù)據(jù)中心，在大型數(shù)據(jù)中心或者種類繁多的設(shè)備和服務(wù)下，人工篩選的方法就不適用了，就要引入數(shù)據(jù)挖掘、機器學(xué)習(xí)的方法對數(shù)據(jù)進

行分析。

（4）需要根據(jù)實際情況建立詳細告警規(guī)則，特征字符匹配僅能實現(xiàn)簡單告警，詳細的告警規(guī)則需要依靠實際生產(chǎn)情況進行制定，如某個IP段對一些服務(wù)區(qū)進行訪問就可以認(rèn)定為異常、在一定時間段內(nèi)登錄密碼錯誤幾次就可以認(rèn)定為異常等。

4 結(jié)束語

本文實現(xiàn)了基于Syslog的網(wǎng)絡(luò)日志管理和分析，對日常網(wǎng)絡(luò)設(shè)備日志進行了收集和分析，通過模式匹配的方法實現(xiàn)了事件檢測和告警，但是在檢測特征字符的選取上更多的是靠人工統(tǒng)計，在準(zhǔn)確程度和效率上都明顯存在不足，引入人工智能的方法對已有的日志數(shù)據(jù)進行分析，提取特征字符，分析運行信息是以后研究的方向。

參考文獻

[1]黃藝海，胡君.日志審計系統(tǒng)設(shè)計與實現(xiàn)[J]，計算機工程，2014，32（22）：67-93.

[2]IETF RFC 3164，The BSD syslog Protocol[S]， C. Lonvick， August 2001.

[3]劉緒忠，王健.未匹配告警SYSLOG智能標(biāo)準(zhǔn)化研究[J]，山東通信技術(shù)，2012，37（01）：40-43.

[4]張驍，應(yīng)時，張韜.應(yīng)用軟件運行日志的收集與服務(wù)處理框架[J]，計算機工程與應(yīng)，2011，54（10）：81-89.

[5]李清，沈彤，關(guān)毅.面向大規(guī)模日志數(shù)據(jù)的聚類算法研究[J].智能計算機與應(yīng)用，2002（05）：42-45.

[6]王衛(wèi)華，應(yīng)時，賈向陽等.一種基于日志聚類的多類型故障預(yù)測方法[J].計算機工程，2013，44（07）：67-73.