譯者注

Peter Bourgon原作： Metrics, tracing, and logging

譯者：吳晟

原作發表時間： 2017年2月21日

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

正文

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

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

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

logging的特點是，它描述一些離散的（不連續的）事件。 例如：應用通過一個滾動的文件輸出debug或error信息，并通過日志收集系統，存儲到Elasticsearch中； 審批明細信息通過Kafka，存儲到數據庫（BigTable）中； 又或者，特定請求的元數據信息，從服務請求中剝離出來，發送給一個異常收集服務，如NewRelic。

tracing的最大特點就是，它在單次請求的范圍內，處理信息。 任何的數據、元數據信息都被綁定到系統中的單個事務上。 例如：一次調用遠程服務的RPC執行過程；一次實際的SQL查詢語句；一次HTTP請求的業務性ID。

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

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

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

另外，我發現通過維恩圖的方式展現三者關系時，會正巧展現出一個附加效應。在這三個功能域中，metric傾向于更節省資源，因為他會“天然的”壓縮數據。相反，日志傾向于無限增加的，會頻繁的超出預期的容量。（有另一篇我寫的關于這方面的文章，查看，譯者注：未翻譯）。所以，我們可以在圖上，繪制出容量的需求趨勢，metrics低到logging高， 而trace可能處于他們兩的中間位置

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

總結

以上是生活随笔為你收集整理的Metrics, tracing 和 logging 的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。