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 官方技術博客。

來源：