Metrics, tracing 和 logging的關系介紹

這篇文章主要介紹“Metrics, tracing 和 logging的關系介紹”，在日常操作中，相信很多人在Metrics, tracing 和 logging的關系介紹問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Metrics, tracing 和 logging的關系介紹”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

正文

今天，我很榮幸的參加了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的關系介紹”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！