[[410184]]

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

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

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

理解日志的挑戰(zhàn)

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

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

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

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

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

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

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

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

機器學習技術(shù)，尤其是異常檢測，通常用于發(fā)現(xiàn)有趣的日志消息。機器學習工具通常要求輸入數(shù)據(jù)作為數(shù)字特征向量，但是將自由的文本日志消息轉(zhuǎn)換為有意義的特征并非易事。一般會分析源代碼，然后從文本日志中自動提取半結(jié)構(gòu)化的數(shù)據(jù)，并將異常檢測應(yīng)用于從日志中提取的特征。

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

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

性能日志分析的挑戰(zhàn)

日志分析可以幫助優(yōu)化或調(diào)試系統(tǒng)性能。理解系統(tǒng)的性能通常與理解如何使用系統(tǒng)中的資源有關(guān)。

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

與調(diào)試用例一樣，必須在上下文中解釋性能日志。其中，有兩種上下文在性能分析中特別有用: 出現(xiàn)性能數(shù)字的環(huán)境和系統(tǒng)的工作負載。

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

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

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

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

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

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

安全日志分析的挑戰(zhàn)

日志還用于應(yīng)用的安全性分析，如檢測違規(guī)或不當行為，以及執(zhí)行安全事件的事后檢查。根據(jù)系統(tǒng)和威脅模型，幾乎任何類型的日志都可以進行安全分析，例如防火墻、登錄會話、資源利用率、系統(tǒng)調(diào)用、網(wǎng)絡(luò)流等相關(guān)的日志。

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

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

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

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

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

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

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

預測的日志分析挑戰(zhàn)

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

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

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

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

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

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

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

雖然這些技術(shù)顯示了統(tǒng)計學習技術(shù)在性能預測方面的威力，但是它們的使用也帶來了一些挑戰(zhàn)。

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

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

報告生成與檔案分析的挑戰(zhàn)

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

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

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

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

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

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

日志的基礎(chǔ)設(shè)施挑戰(zhàn)

日志的基礎(chǔ)設(shè)施對于支持各種應(yīng)用程序至關(guān)重要。它至少需要兩個特性: 日志生成和日志存儲。

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

在存儲方面，基礎(chǔ)設(shè)施聚合來自各種網(wǎng)絡(luò)源的消息。Splunk 為來自 syslog 和其他源的非結(jié)構(gòu)化文本日志編制索引，并對數(shù)據(jù)執(zhí)行實時和歷史分析。使用 Hadoop 存儲數(shù)據(jù)，以利用分布式計算的基礎(chǔ)設(shè)施。

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

• 每 TB 的成本(包括前端和維護)
• 總?cè)萘?/li>
• 持久性保證
• 寫訪問特性(例如，帶寬和延遲)
• 讀取訪問特性(隨機訪問 vs 順序掃描)
• 安全考慮(訪問控制和規(guī)則遵從性)
• 與現(xiàn)有基礎(chǔ)設(shè)施的集成

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

日志存儲解決方案在與警報和報表功能結(jié)合時更有用。這樣的基礎(chǔ)架構(gòu)可以用于調(diào)試、安全性和其他系統(tǒng)管理任務(wù)。各種日志存儲解決方案促進了告警和報表功能，但是它們留下了許多與告警節(jié)流、報表加速和預測能力有關(guān)的開放挑戰(zhàn)。

總結(jié)

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

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

其次，日志記錄過程本身需要額外的管理?？刂迫罩镜娜唛L性對于管理開銷和促進分析非常重要，尤其是在出現(xiàn)峰值或潛在攻擊行為的情況下。日志記錄機制也不應(yīng)該成為傳播惡意活動的通道。在最大化信息內(nèi)容的同時最小化檢測開銷仍然是一個挑戰(zhàn)。

第三個挑戰(zhàn)是，盡管各種分析和統(tǒng)計建模技術(shù)可以挖掘大量的日志數(shù)據(jù)，但它們并不總能提供可操作的洞察力。例如，統(tǒng)計技術(shù)可以揭示工作負載中的異?；蛘呦到y(tǒng)的 CPU 利用率過高，但是不能解釋如何處理它。信息的解讀具有主觀性，信息是否具有可操作性取決于多種因素。這是重要的調(diào)查技術(shù)，是效率，準確性和可行性的權(quán)衡。

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

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

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

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