2.4 系統日志的數據形式

系統日志和事件的數據存儲形式主要有兩類。一類是無結構的日志數據，例如日志文件，常見的Linux日志、Apache服務器日志、Hadoop 日志等的日志數據都記錄在一個純文本日志文件中。每條日志或者事件都以一條文本消息或者短文的形式存儲在日志文件內。另外一類是結構化或者半結構化的日志事件數據，比如Windows Event Logs、數據庫歷史查詢記錄日志以及IBM Tivoli Monitoring[17]監測事件等。每條數據庫記錄代表一個日志或者事件。每條記錄會將該日志事件的各個屬性分開存儲到表的各個字段內。常見的字段包括日志產生的時間、機器名、進程名、錯誤代碼、異常詳細描述等。

2.4.1 無結構的日志數據

圖2-3是一個Hadoop平臺下DataNode的日志文件。

每條日志大概分3個部分：日志產生的日期和時間；日志產生的Java類；消息。消息部分的內容是Hadoop開發人員定義在Hadoop源代碼內部的。消息部分描述了當前程序在執行何種任務或者遇到何種錯誤異常。這些日志數據都是在標準 Java logging工具（例如apache common logs、log4j等）下生成的。例如，第一條記錄表示在2011-01-26 10：38：49這個時刻，該Hadoop的DataNode類在執行STARTUP （啟動）這個事件。第二條記錄則是表示一個錯誤異常信息：NullPointerException（空指針異常）。第三條記錄則是這個DataNode類主動發起SHUTDOWN_MSG（關閉）的時間。直到第 7 條記錄，該 DataNode 得以成功啟動。整體來說，每條日志記錄都是描述一個系統事件，且可以由一個標準事件的三元組構成（時間、地點、行為）。正因如此，本書將系統事件和系統日志看作同一個概念。

很多應用程序并沒有標準的日志格式。諸如一些 UNIX/Linux 下開發的應用軟件可能使用其他的日志生成代碼。甚至在同一個軟件系統內，不同模塊生成的日志格式也完全不一樣，因為不同模塊的開發可能是由不同開發團隊或者公司完成的，且團隊和公司之前并沒有統一格式規范。另外，由于日志功能需求上的不同，不同軟件系統生成的日志格式也可能完全不一樣。例如當開發人員十分注重一個軟件的數據吞吐量的時候，他們會在日志數據中嵌入大量衡量數據吞吐量的標準。當開發人員更注重一個軟件的業務邏輯和執行步驟的時候，他會更多地在日志數據中嵌入業務邏輯的描述?？偟膩碚f，系統日志數據千差萬別。在處理一個具體系統的日志時，分析方法可能也會千差萬別。一個很現實的問題就是：大量開源軟件和商業軟件沒有詳盡的關于日志數據的文檔說明。這對于人工和自動的日志分析都是一大挑戰。很多日志分析的工作都依賴于系統管理員在此領域的個人經驗。在后面的章節里，我們也會針對此問題介紹一些基于數據挖掘算法分析此類日志數據的方法。

2.4.2 結構化與半結構化的日志數據

最常見的半結構化日志數據就是Windows Event Logs。圖2-4是一個Windows 7的Event Viewer應用程序的截圖。Event Viewer是Windows操作系統內查看Windows Event Logs數據的圖形界面程序。Windows系統大致把其Event Logs分成五大類：Application、Security、Setup、System、Forwarded Events。Application是Windows操作系統內的應用程序生成的日志數據。Security 是與安全相關的事件，比如Windows自身的防火墻會阻擋某些外部TCP請求，這些被阻擋的TCP請求就會被記錄在這部分日志數據內。Setup主要是應用程序的安裝和Windows組件的安裝、卸載以及修改等事件，比如最典型的就是Windows Update補丁的安裝記錄。System是系統內部運行狀態的各種日志數據，比如某個服務被停止、某個服務進程被開啟等。Forwarded Events是從其他計算機轉發的信息。

圖2-5是一個原始XML的Security事件日志。通過XML的各個標簽可以很清楚地看到這個事件發生的事件名、機器名、用戶名、域名、進程名以及創建進程的執行文件路徑。圖2-5中的機器名、域名和用戶名被xxx取代。此類日志數據可以通過常見的 XML 解析軟件得到各個關鍵的事件屬性，這對于自動化的日志數據分析來說是一大便利之處。

除了 Windows Event Logs 之外，很多系統監控系統（比如 IBM Tivoli Monitoring[20]、HP OpenView[21]）生成的日志事件數據也是以半結構化的形式存儲在關系數據庫內。不同之處在于，專業監控系統可以通過管理員定制各種復雜的監控信息，產生各種不同的日志數據。以IBM Tivoli Monitoring為例，它可以讓監控管理員監控硬件設備、操作系統內核，甚至Web內部消息的所有信息。這些日志數據并不保存在服務器自身的文件系統中，而是直接寫入海量數據中心的關系數據庫或者NoSQL數據庫[22]。系統管理員可以通過SQL語句查詢其關注的某些日志事件。有效管理海量系統日志屬于數據庫和數據挖掘領域的一個交織應用領域。在工業界，除了 IBM、HP 等大企業之外，也有很多專門的企業和商業軟件提出各種不同的體系架構和解決方案，如Splunk[18]、AppFirst[19]。

2.4.3 非結構化數據的轉換

很多數據挖掘的分析算法都建立在結構化的事件上，但是有很多日志數據是半結構或者無結構化的文本。在進行分析之前，我們需要將這種文本數據轉換成為結構化的事件[23]。在傳統的自然語言處理領域，這個任務就是典型的信息抽取。信息抽取有基于規則的，也有基于統計模型的。基于規則的方法比較簡單，也比較實用。在學術界，大家研究更多的是基于統計模型的，例如Conditional Random Field[24]等。對于系統日志數據來說，格式和變化相對于人類語言其實很小，無論是用基于規則還是基于Conditional Random Field的方法都完全可以取得很高的精確度，而且比一般自然語言處理的文本的處理結果更可靠。

在沒有訓練數據的情況下，無結構的日志數據轉換還可以通過分析其日志生成的源代碼完成[25]。現在很多軟件都有專門的日志生成工具包，例如用java.util.logging和Apache Log4J[26]等標準庫來規范日志。換句話說，這些日志生成源代碼并沒有多大的變化，通過源代碼文件中的字符串匹配就可以找到生成日志的函數代碼。然后再對其進行類似形式語言的語法處理，就可以抽取出日志里的字符串和變量。

很多商業軟件系統的源代碼并不是可以獲取的。即便可以獲取，也不一定是完整的，因為一個軟件系統可能用了無數第三方的軟件庫或者工具包。再次，大型軟件系統的源代碼太龐大，除了軟件供應開發商之外，由其他任何機構來整理和分析都是一個浩大的工程。參考文獻[27]提出一種基于聚類算法將文本日志轉換成為各種不同類型事件的方法。其中，每條日志文本的距離通過簡單的逐詞匹配獲取。兩條文本日志在每個位置上互相匹配的詞越多，就認為這兩條文本日志的距離越小。參考文獻[28]提出的是一種基于層次的聚類算法。每層抽取不同的日志文本格式信息進行聚類。這兩類方法對日志文本的格式一致性要求太高。如果兩個日志文本長度不一樣，或者說有些細節變化，都將導致日志文本完全歸為不同類別。參考文獻[29]針對文本日志提出一種基于短語標簽（Signature）的方式進行聚類。這里的短語標簽通常是代表一類日志事件特色的短語結構，如“database tablespace”“paging switch”。日志文本通常很短，一旦出現這類短語，就能足夠準確地將該日志文本進行分類。短語標簽的提出思想來自于最長公共子串（Multiple Longest Common Subsequence）問題[30]。需要注意的是，在一般算法教程里介紹動態規劃的時候，都是用2個串來尋找最長公共子串的。這里的Multiple Longest Common Subsequence是一個擴展問題，假設我們有n個串，那么最長的共同子串是什么？公共子串不要求一定由連續的詞組成，所以它的頑健性比前面的方法都強。但是尋找n個串的最長公共子串是一個著名的NP難問題[29]?；诙陶Z標簽的聚類算法的目標就是將所有的日志文本集分成k個簇，并從每個簇找出一個短語標簽，然后試圖讓簇內的日志文本盡量和這個短語標簽匹配。與最長公共子串問題不同的是，這里并不要求短語標簽被所有的簇內日志文本所包含，而是計算一個匹配度的量化指標。但是這個問題依然可以被證明和n個串的最長公共子串問題的難度是等價的。具體的近似算法見參考文獻[29]。