[[410184]]

計算機的系統日志提供了對正在運行的系統狀態的描述。日志的內容和格式在不同的系統之間，甚至在系統中的不同組件之間都可能有著很大的不同。硬件的驅動程序可能生成指示與硬件通信有問題的消息，而 Web 服務器可能記錄請求了哪些頁面以及何時請求其他服務。

由于日志的內容不同，用途也有著相應的不同。有關硬件的日志可用于故障排除，而 web 服務器日志用于研究流量模式以最大化業務收入。事實上，單個日志可以用于多種用途: 關于沿著不同網絡路徑(稱為流量)的信息可能有助于用戶優化網絡性能或檢測惡意入侵; 或者通話記錄可以監控誰和何時撥打了電話，并通過進一步分析可以揭示整個城市的通話量和掉話率。

日志分析是一個豐富的研究領域，但仍然面臨著諸多的挑戰。那為什么日志分析既重要又困難呢?

理解日志的挑戰

許多日志旨在促進調試。“最有效的調試工具仍然是仔細的思考，再加上明智的 print 語句。”盡管今天的程序比30年前的程序復雜了4個數量級，許多人仍然使用 printf 來記錄控制臺或本地磁盤的日志，并使用一些手動檢查和正則表達式的組合來定位特定的消息或模式。

調試日志最簡單也是最常見的用途是對特定消息使用 grep。如果認為程序因為網絡故障而崩潰，那么可能會嘗試在服務器日志中找到“連接丟失”消息。在許多情況下，很難確定要搜索什么，因為日志消息和觀察到的癥狀之間沒有定義良好的映射。當 Web 服務突然變慢時，不太可能看到一個明顯的錯誤消息說，“ ERROR: 服務延遲增加了10% ，因為第 x 行的 bug 被觸發了。”相反，用戶通常會搜索嚴重性關鍵字，比如“ error”或“ failure”。然而，這樣的嚴重級別經常沒有被準確地使用，因為開發人員很少完全了解最終將如何使用這些代碼。

當開發人員編寫日志消息的 print 語句時，它被綁定到程序源代碼的上下文。然而，信息的內容通常排除了這個上下文。如果不了解 print 語句周圍的代碼，或者不知道是什么導致程序進入了執行路徑，消息的一些語義可能會丟失，也就是說，在沒有上下文的情況下，日志消息可能難以理解。

另一個挑戰是，日志文件通常被設計為表示單個事件流。然而，來自多個源的消息可能在運行時(來自多線程或多進程)和靜態模塊交錯。對于運行時的交織，線程 ID 不能解決問題，因為可以為獨立任務重用線程。一直以來，人們努力自動包含消息上下文(例如，X-Trace) ，或者從消息內容中進行推斷，但是這些都不能完全捕獲開發人員的意圖和期望。

靜態交織場景更具挑戰性，因為不同的模塊可能由不同的開發人員編寫。因此，單個日志消息可能有多種解釋。例如，“連接丟失”可能對網絡庫的作者非常重要，但對于通過底層抽象避免錯誤的應用程序作者來說就不那么重要了。共享庫的作者通常不可能預測哪些消息對用戶有用。

日志記錄通常意味著一些內部同步。這可能會通過改變線程交織模式和模糊問題而使多線程系統的調試復雜化。一個程序只在某些執行點上表現出不確定性，比如時鐘中斷和 i/o 通過記錄所有不確定的執行點，一般要重新運行整個程序來進行觀察，可以在重新運行之前修改一些代碼來觀察程序中的任何東西。然而，對于并發程序或那些確定性執行依賴于大量數據的程序，這種方法可能是不切實際的。

在大型系統中，日志量可能過大。例如，為了調試鎖競爭而對鎖對象上的每個獲取和釋放操作進行日志記錄可能會代價過高。在多模塊系統中，更加困難，因為日志也是異構的，因此更不適合進行直接分析。收集、存儲、排序或索引大量日志消息存在著固有的成本，其中許多消息可能永遠不會被使用。調試日志的投資回報來自其診斷能力，這是很難衡量的。

有些用戶需要的是聚合或統計信息，而不是單獨的消息。在這種情況下，他們只能記錄聚合數據或聚合數據的近似值，仍然可以得到所需統計數據的良好估計，近似提供了對于諸如 PCA 和 SVM這樣的機器學習分析。這些技術在網絡化或大規模分布式系統中非常關鍵，在這些系統中，即使從每個組件收集一個數字也會帶來沉重的性能成本。這說明了裁剪工具對于特定分析的潛在好處。

機器學習技術，尤其是異常檢測，通常用于發現有趣的日志消息。機器學習工具通常要求輸入數據作為數字特征向量，但是將自由的文本日志消息轉換為有意義的特征并非易事。一般會分析源代碼，然后從文本日志中自動提取半結構化的數據，并將異常檢測應用于從日志中提取的特征。

統計異常檢測仍然面臨挑戰。即使某些信息在統計意義上是不正常的，也可能沒有進一步的證據表明這些信息是原因、癥狀，或者僅僅是無害的。此外，統計方法在很大程度上依賴于日志質量，特別是是否記錄了“重要”事件，而這些方法本身并沒有定義什么是“重要的”。

靜態程序分析可以通過分析程序中可能導致消息產生的路徑來幫助發現特定消息的根本原因。靜態分析還可以通過尋找分歧點來揭示提高日志質量的方法，程序執行可能從這些分歧點進入錯誤路徑; 這些分歧點是日志分析的最佳選擇。目標系統的啟發式和領域知識通常使這種分析更有效。

性能日志分析的挑戰

日志分析可以幫助優化或調試系統性能。理解系統的性能通常與理解如何使用系統中的資源有關。

有些日志與調試的情況相同，例如記錄并鎖定操作以調試瓶頸。有些日志跟蹤單個資源的使用情況，會產生一個時間序列。資源使用統計數據通常以每個時間段累積使用的形式出現(例如，在最后一分鐘傳輸的n個字節)，使用帶寬數據描述網絡或磁盤性能，頁交換描述內存有效性，或者 CPU 利用率描述負載平衡質量。

與調試用例一樣，必須在上下文中解釋性能日志。其中，有兩種上下文在性能分析中特別有用: 出現性能數字的環境和系統的工作負載。

性能問題通常由組件之間的交互引起，為了揭示這些交互，可能必須綜合來自多個源生成的異構日志的信息。合成可能是一個挑戰。除了異構的日志格式之外，分布式系統中的組件可能在確切的時間上存在分歧，使得跨多個組件事件的精確排序無法重構。另外，對一個組件無害的事件(例如，將日志刷新到磁盤)可能會對另一個組件造成嚴重問題(例如，I/O的資源競爭)。由于引起問題的組件不太可能記錄事件，因此可能很難捕獲這個根本原因。這只是所出現困難中的一小部分。

解決這個問題的一個方法是計算影響力，通過尋找令人驚訝的、在時間上相關的行為來推斷組件或組件之間的關系。即使這些日志是稀疏的、不完整的、沒有已知的語義，即使交互機制是未知的，也需要量化產生異構日志的組件之間的交互。

在消息或請求被系統處理時，對其進行跟蹤的方法能夠說明事件的順序和工作負載的影響。例如，一種類型的請求可以很容易地通過緩存數據進行服務，而另一種類型的請求則不能。這種跟蹤方法通常需要能夠提供支持的檢測工具，但是除了了解性能之外，它對正確性調試也很有用。

這方面的一個突出挑戰是測量行為對影響測量本身的風險。耗費資源的大量日志記錄可能會使首先這些資源的任務復雜化。我們測量的越多，我們就越不能準確地理解系統的性能特征。即使是保守的跟蹤機制在實踐中也通常會引入不可接受的開銷。

減少日志記錄對性能影響的一種方法是抽樣。危險在于，抽樣調查可能會錯過罕見的事件。但是，如果有數百萬乃至數億個采樣實例在運行，那么在可以在捕獲罕見事件的同時保持較低的采樣率。

采樣技術的有效實現需要能夠打開和關閉單個日志站點，而不需要重新啟動執行。像 DTrace 這樣的舊系統仍然需要靜態檢測的日志站點，但是，日志的后處理是一個收集、處理和分析軟件執行跟蹤的平臺，它允許用戶指定他們想要測量的事件，用聲明性語言表述為查詢; 然后平臺在運行的系統中插入動態的plug-in，聚合測量數據，并提供分析機制，所有這些都是針對這些查詢的。當應用于分布式系統中的基準代碼時，這樣的系統顯示了個位數的開銷百分比。結合基于抽樣的日志記錄的動態日志記錄可能是解決需要大規模詳細日志記錄問題的關鍵方案。

安全日志分析的挑戰

日志還用于應用的安全性分析，如檢測違規或不當行為，以及執行安全事件的事后檢查。根據系統和威脅模型，幾乎任何類型的日志都可以進行安全分析，例如防火墻、登錄會話、資源利用率、系統調用、網絡流等相關的日志。

入侵檢測通常需要根據日志重建會話。考慮一個與入侵檢測相關的例子，即檢測對系統的未經授權的訪問。當用戶通過 SSH 遠程登錄到計算機時，計算機將生成與登錄事件相對應的一條日志。在 Mac OS x 上，這些消息顯示一個名為 XX的用戶從特定的 IP 地址和端口號交互地訪問了機器。

常識告訴我們，注銷消息應該與之前的登錄消息相匹配，但是，有些日志行沒有任何語法可以先驗地揭示它們以某種方式與登錄時生成的代碼行相關聯，更不用說彼此之間了。換句話說，每個消息都是多個語義事件的證據，包括以下內容: 特定代碼行的執行、 SSH 會話的創建或銷毀，以及作為一個整體的 SSH 會話。

對安全性感興趣的日志分析可能會問一個看似簡單的問題: 這個 SSH 會話是否構成安全性破壞?

答案可能取決于一些因素，其中包括: 是否有異常大量的登錄嘗試失敗最近?用戶XX的 IP 地址熟悉嗎?XX 在會話處于活動狀態時是否執行了任何可疑的操作?用戶名為 XX的用戶是否正在休假，因此不應該登錄?

需要注意的是，只有其中一些問題可以使用日志中的數據來回答。例如，可以查找在這個會話之前的大量失敗的登錄嘗試，但是不能推斷XX的真實身份，更不用說他或她的假期計劃了。因此，分析的能力受到日志中信息的限制。

安全性的日志分析可以是基于簽名的，用戶嘗試檢測已知的惡意行為; 或者是基于異常事件，尋找偏離典型或良好行為并將其標記為可疑行為。簽名的方法可以可靠地檢測到與已知簽名匹配的攻擊，但對不匹配的攻擊不敏感。另一方面，異常方法面臨著設置一個閾值來調用可疑異常的困難: 過低，錯誤警報使工具無用; 過高，攻擊可能未被發現。

應用的安全性還面臨著與敵人斗智斗勇。為了避開日志分析工具的注意，攻擊者將試圖使攻擊期間生成的日志看起來與正確操作期間生成的日志完全或接近相同。對于不完整的日志，分析無能為力。開發人員可以嘗試提高日志記錄覆蓋率，這使得對手更難避免留下活動的證據，但這并不一定使區分“健康”日志和“可疑”日志變得更容易。

預測的日志分析挑戰

日志數據可以用來預測。預測模型有助于實現資源供應、容量規劃、工作負載管理、調度和配置優化的自動化或提供數據方面的洞察力。從商業角度來看，預測模型可以指導營銷策略、廣告投放或庫存管理。

針對具體的系統，建立并完善了一些分析模型。專家手動識別依賴關系和相關度量標準，量化組件之間的關系，并設計預測策略。這些模型通常用于構建模擬器，模擬器重播預期的工作負載擾動或負載量，以提出假設問題。在I/O子系統、磁盤陣列、數據庫和靜態 Web 服務器上都有使用分析模型進行性能預測的示例。然而，這種方法有一個重大的實際缺點，即實際系統變化頻繁，分析技術必須要跟上這些變化。

盡管建模技術可能在不同的系統中是通用的，但是為構建模型而挖掘的日志數據以及預測的度量可能會有所不同。例如，I/O 子系統和包含時間戳、事件類型、 CPU 配置文件以及其他每個操作系統的事件來預測 I/O 子系統的性能，也可以利用捕獲 I/O 請求速率、請求大小、運行計數、隊列長度和其他屬性的跟蹤來構建分析模型，以預測磁盤陣列吞吐量。

許多分析模型都是單層的: 每個預測指標都有一個模型。在其他場景中，需要一個模型層次結構來根據其他性能指標來預測單個性能指標。例如，使用包含時間戳、請求類型(GET vs. POST)、請求的字節、 URI 和其他字段的 Web 服務器跟蹤來預測存儲響應時間、存儲 I/O 和服務器內存。預測不同負載條件下服務器響應時間的模型可以由存儲量和服務器內存模型組成。另一個例子是，日志跟蹤記錄訪問、塊訪問、物理磁盤傳輸、吞吐量和平均響應時間可用于建立多級排隊的網絡模型，以預測物理和邏輯設計決策對數據庫性能的影響。

分析模型的一個缺點是需要特定于系統的領域知識。這樣的模型不能無縫地移植到新版本的系統，更不用說移植到其他系統了。隨著系統變得越來越復雜，人們開始轉向使用歷史數據的統計模型來預測未來的工作量和性能。

回歸分析是用于預測的最簡單的統計建模技術。它已經應用于性能計數器，用于度量執行時間和內存子系統的影響。例如，應用于這些日志的線性回歸被用來預測并行處理器上庫的數據分區布局的執行時間。而應用邏輯回歸模型被用來預測一組好的編譯器標志。CART 使用磁盤請求的跟蹤，指定到達時間、邏輯塊號、請求的塊和讀/寫類型，以預測存儲系統中請求和工作負載的響應時間。

簡單回歸和 CART 模型都可以預測每個模型的單一指標。然而，性能指標通常具有相互依賴性，必須對每個指標進行預測，才能做出明智的調度或配置決策。為了同時預測多個指標，有一種方法是采用典型的相關分析來建立一個模型，該模型捕捉系統輸入和性能特征之間的相互依賴關系，并利用該模型來預測系統在任意輸入下的性能。、

雖然這些技術顯示了統計學習技術在性能預測方面的威力，但是它們的使用也帶來了一些挑戰。

從事件日志中提取特征向量是影響預測模型有效性的關鍵步驟。事件日志通常包含非數字數據(例如，分類數據) ，但統計技術期望數字輸入帶有在數據上定義的分布概念。將事件中的非數值信息轉換為有意義的數值數據可能非常繁瑣，需要了解事件代表什么的領域知識。因此，即使給出一個預測，也很難確定正確的行動方向。

預測模型通常提供一個值的范圍，而不是一個單一的數字; 這個范圍有時代表一個置信區間，這意味著真正的價值很可能在這個區間內。是否對預測采取行動是一個必須權衡置信度與成本的決定，也就是說，對低置信度預測采取行動未必比什么都不做要好。執行可能取決于日志粒度是否與決策粒度匹配，例如，每個查詢的資源利用率的日志無助于任務級別的調度決策，因為對并行性和較低級別的資源利用指標了解的并不足夠。

報告生成與檔案分析的挑戰

日志分析的另一個用途是分析資源利用率、工作負載或用戶行為。記錄集群工作負載中任務特征的日志可用于分析大型數據中心的資源利用情況。可以利用相同的數據來了解工作負載中作業之間的相互到達時間，以及日變化模式。

除了系統管理之外，還可以還用于業務分析。例如，Web 服務器日志描述了 站點訪問者的特征，它可以產生客戶統計信息。Web 日志分析技術的范圍從捕獲頁面流行趨勢的簡單統計演化成了描述跨多個用戶會話訪問模式的復雜時間序列方法。這些數據為營銷活動、內容托管和資源供應提供了信息。

使用各種統計技術來分析和報告日志數據。聚類算法，如 k 均值和層次聚類組得到相似事件。馬爾可夫鏈被用于模式挖掘，其中時間序列是必不可少的。

許多剖析和警報技術需要專家知識形式的提示。例如，K均值聚類算法要求用戶指定集群的數量(k)或者提供作為種子集群中心的示例事件。其他技術需要合并或分區聚類的啟發式算法。大多數技術依賴于事件的數學表示，并且分析結果以類似的術語表示。然后，可能有必要將這些數學表示映射進行還原，如果不理解日志語義，這可能會很困難。

對日志事件進行分類通常也具有挑戰性。例如，要對系統性能進行分類，可以分析 CPU 利用率和內存消耗情況。假設有一個高 CPU 利用率和低內存消耗的性能配置文件，以及一個具有低 CPU 利用率和高內存消耗的單獨配置文件; 當出現一個包含低 CPU 利用率和低內存消耗的事件時，不清楚它應該屬于兩個配置文件中的哪一個(或兩者)。如果有足夠多的此類事件，最好的選擇可能是包含第三個配置文件。對于如何處理跨多個摘要的事件或者如何預先創建這樣的摘要，并沒有普遍適用的規則。

盡管摘要可以有效地對類似事件進行分組，并提供系統行為的高級視圖，但它并不能直接轉化為可操作的洞察力。解釋摘要并使用它來做業務決策、修改系統、甚至修改分析的任務通常落在人的身上。

日志的基礎設施挑戰

日志的基礎設施對于支持各種應用程序至關重要。它至少需要兩個特性: 日志生成和日志存儲。

大多數通用日志都是非結構化文本。開發人員使用 printf 和字符串連接來生成消息，這些原語已經被很好地理解并且無處不在。然而，這種日志記錄方式也有缺點。首先，將變量序列化為文本的代價高昂。其次，分析需要解析文本消息，這也可能是復雜而昂貴的。

在存儲方面，基礎設施聚合來自各種網絡源的消息。Splunk 為來自 syslog 和其他源的非結構化文本日志編制索引，并對數據執行實時和歷史分析。使用 Hadoop 存儲數據，以利用分布式計算的基礎設施。

選擇正確的日志存儲解決方案需要權衡以下因素:

• 每 TB 的成本(包括前端和維護)
• 總容量
• 持久性保證
• 寫訪問特性(例如，帶寬和延遲)
• 讀取訪問特性(隨機訪問 vs 順序掃描)
• 安全考慮(訪問控制和規則遵從性)
• 與現有基礎設施的集成

對于日志保留，不存在一個放之四海而皆準的策略。這使得選擇和配置日志解決方案成為一個挑戰。對商業智能有用的日志通常被認為比調試日志更重要，因此保存的時間更長。相比之下，大多數調試日志盡可能長時間地存儲，但是沒有保存的保證，這意味著它們可能在資源壓力下被刪除。

日志存儲解決方案在與警報和報表功能結合時更有用。這樣的基礎架構可以用于調試、安全性和其他系統管理任務。各種日志存儲解決方案促進了告警和報表功能，但是它們留下了許多與告警節流、報表加速和預測能力有關的開放挑戰。

總結

現在的系統管理在很大程度上已經變得以日志為中心。無論是用于調試問題還是用于提供資源，日志都包含了大量可以精確定位或至少暗示解決方案的信息。

雖然日志分析技術已經取得了很大進展，但仍然存在一些較大的挑戰。首先，隨著系統越來越多地由許分布式組件構成，使用單個日志文件來監視來自系統不同部分的事件是很困難的。在某些情況下，來自完全不同系統的日志必須交叉關聯才能進行分析。交織異構日志很少是直接的，特別是當時間戳沒有在所有日志中同步或出現，而且組件之間語義不一致的時候。

其次，日志記錄過程本身需要額外的管理。控制日志的冗長性對于管理開銷和促進分析非常重要，尤其是在出現峰值或潛在攻擊行為的情況下。日志記錄機制也不應該成為傳播惡意活動的通道。在最大化信息內容的同時最小化檢測開銷仍然是一個挑戰。

第三個挑戰是，盡管各種分析和統計建模技術可以挖掘大量的日志數據，但它們并不總能提供可操作的洞察力。例如，統計技術可以揭示工作負載中的異常或者系統的 CPU 利用率過高，但是不能解釋如何處理它。信息的解讀具有主觀性，信息是否具有可操作性取決于多種因素。這是重要的調查技術，是效率，準確性和可行性的權衡。

由于在可預見的未來，人仍然是解釋和處理日志過程的一部分，因此可視化技術的是值得投入的。

程序分析方法，無論是靜態的還是動態的，都有望提高我們自動描述導致特定日志消息序列的交互能力，使日志要么更易于進行各種分析，要么提供更全面的信息。對于如何生成更有用的日志的洞察力通常伴隨著對于如何分析現有日志的洞察力，驗證日志消息有效性的機制將提高日志質量，使日志分析更加有效。

隨著許多企業越來越依賴于他們的計算機基礎設施，這種關系的重要性也隨之增加。已經看到越來越多的工具試圖推斷系統是如何影響用戶的: 延遲如何影響購買決策; 點擊模式如何描述用戶滿意度; 以及資源調度決策如何改變對這些資源的需求。另外，用戶活動可能對系統調試有用。進一步探索用戶行為(工作負載)和系統行為之間的關系，可能有助于理解要使用什么日志，何時使用以及用于什么目的。

更好的日志標準和最佳實踐，將有助于提高日志分析的水平。