OneAPM大講堂 | Metrics, Tracing 和 Logging 的關係

【編者按】這是在 OpenTracing 和分散式追蹤領域內廣受歡迎的一片部落格文章。在構建監控系統時，大家往往在這幾個名詞和方式之間糾結。 通過這篇文章，作者很好的闡述了分散式追蹤、統計指標與日誌之間的區別和關係。

Peter Bourgon 原作： Metrics, tracing, and logging

譯者：吳晟

正文

今天，我很榮幸的參加了 2017 分散式追蹤峰會(2017 Distributed Tracing Summit)， 並和來自 AWS/X-Ray, OpenZipkin, OpenTracing, Instana, Datadog, Librato，以及其他更多組織的同仁進行了愉快的溝通和討論。 其中一個重要的論點，是針對監控專案的範圍和定義的。作為一個分散式追蹤系統，應該管理日誌麼?從不同角度看來，到底什麼是日誌?如何通過一張圖形象的定位這些形形色色的系統?

總體說來，我覺得我們是在一些通用的名詞間糾結。我想我們可以通過圖表來定義監控的作用域，使各名詞的作用範圍更明確。 我們使用維恩圖(Venn diagram)來描述 Metrics, Tracing, Logging 三個概念的定義。他們三者在某些情況下是重疊的，但是我儘量嘗試定義他們的不同。如下圖所示：

Metrics 的特點是，它是可累加的：他們具有原子性，每個都是一個邏輯計量單元，或者一個時間段內的柱狀圖。 例如：佇列的當前深度可以被定義為一個計量單元，在寫入或讀取時被更新統計; 輸入 HTTP 請求的數量可以被定義為一個計數器，用於簡單累加; 請求的執行時間可以被定義為一個柱狀圖，在指定時間片上更新和統計彙總。

Logging 的特點是，它描述一些離散的(不連續的)事件。 例如：應用通過一個滾動的檔案輸出 Debug 或 Error 資訊，並通過日誌收集系統，儲存到 Elasticsearch 中; 審批明細資訊通過 Kafka，儲存到資料庫(BigTable)中; 又或者，特定請求的後設資料資訊，從服務請求中剝離出來，傳送給一個異常收集服務，如 NewRelic。

Tracing 的最大特點就是，它在單次請求的範圍內，處理資訊。 任何的資料、後設資料資訊都被繫結到系統中的單個事務上。 例如：一次呼叫遠端服務的 RPC 執行過程;一次實際的 SQL 查詢語句;一次 HTTP 請求的業務性 ID。

根據上述的定義，我們可以標記上圖的重疊部分。

當然，大量的被監控的應用是具有分散式能力(Cloud-native)的應用，邏輯處理在單次請求的範圍內完成。因此，討論追蹤的上下文是有意義的。 但是，我們注意到，並不是所有的監控系統都繫結在請求的生命週期上的。他們可能是邏輯元件診斷資訊、處理過程的生命週期明細資訊，這些資訊和任何離散的請求時正交關係。 所以，不是所有的 Metrics 和 Log 都可以被塞進追蹤系統的概念中，至少在不經過資料加工處理是不行的。又或者，我們可能發覺使用 Metrics 統計資料，對應用監控有很大幫助，例如 Prometheus 生態，可以量化的實時展現應用檢視;相應的，如果我們將 Metrics 統計資料強行使用針對 Log 的管道來處理，將使我們丟失很多特性。

那麼，在這裡，我們可以開始對已知的系統進行分類。如：Prometheus， 專一的 Metrics 統計系統，隨著時間推移，也許會進化為追蹤系統，進而進行請求內的指標統計，但不太可能深入到 Log 處理領域。ELK 生態提供 Log 的記錄，滾動和聚合，並在其他領域不停的積累更多的特性，並整合進來。

另外，我發現通過維恩圖的方式展現三者關係時，會正巧展現出一個附加效應。在這三個功能域中，Metrics 傾向於更節省資源，因為他會“天然的”壓縮資料。相反，日誌傾向於無限增加的，會頻繁的超出預期的容量。(有另一篇我寫的關於這方面的文章，檢視，譯者注：未翻譯)。所以，我們可以在圖上，繪製出容量的需求趨勢，Metrics 低到 Logging 高， 而 Trace 可能處於他們兩的中間位置

也許，這不是最完美的方式描述這三者的管理，但我從會議現場收到的反饋來看，這個分類還是相當不錯的：隨著三者的關係越清晰，我們越容易建設性的討論其他問題。如果你嘗試對產品的功能進行定位，你可能也需要這張圖，在討論中，澄清產品的位置。

OneAPM Li** 智慧日誌分析平臺可以實時收集資料中心基礎架構及應用的海量日誌，實時搜尋，實時分析，洞悉日誌價值。想閱讀更多技術文章，請訪問 **OneAPM 官方技術部落格。 來源：http://blog.oneapm.com/apm-tech/811.html