今天，我有幸參加了2017年的分布式追蹤峰會，其中有很多來自AWS / X-Ray，OpenZipkin，OpenTracing，Instana，Datadog，Librato等公司的人員，我很遺憾我忘記了這一點。有一次討論轉向了項目范圍和定義。跟蹤系統是否也應該管理日志記錄？什么確實的記錄，通過在室內所代表的不同的鏡頭看？所有各種混凝土系統在哪里適合圖片？

簡而言之，我覺得我們在共享詞匯中磕磕絆絆了一下。我認為我們可能會將儀器或可觀察性的領域映射為一種維恩圖。度量，跟蹤和日志記錄絕對是更廣泛圖景的所有部分，并且在某些情況下肯定會重疊，但我想嘗試識別每個真正不同的屬性。我想過喝咖啡休息時間想出來。

?

我認為度量的定義特征是它們是可聚合的：它們是在一段時間內組成單個邏輯規范，計數器或直方圖的原子。作為示例：隊列的當前深度可以被建模為規范，其更新與last-writer-win語義聚合;?傳入的HTTP請求的數量可以建模為計數器，其更新通過簡單的加法聚合;?并且觀察到的請求持續時間可以被建模為直方圖，其更新聚合成時間段并產生統計摘要。

我認為日志記錄的定義特征是它處理離散事件。例如：通過syslog將輪換文件描述符發送到Elasticsearch（或OK Log，nudge nudge）的應用程序調試或錯誤消息;?審計跟蹤事件通過Kafka推送到像BigTable這樣的數據湖;?或從服務調用中提取的特定于請求的元數據，并將其發送到像NewRelic這樣的錯誤跟蹤服務。

我認為，跟蹤的唯一定義特征是它處理請求范圍的信息。可以綁定到系統中單個事務對象的生命周期的任何數據或元數據。例如：出站RPC到遠程服務的持續時間;?發送到數據庫的實際SQL查詢的文本;?或入站HTTP請求的相關ID。

通過這些定義，我們可以標記重疊部分。

?

當然，云原生應用程序的許多典型工具最終都是請求范圍的，因此在更廣泛的跟蹤環境中討論可能是有意義的。但我們現在可以觀察到并非所有儀器都必然會請求生命周期：例如，邏輯組件診斷信息或流程生命周期細節與任何離散請求正交。因此，例如，并非所有指標或日志都可以被追溯到跟蹤系統 - 至少，不是沒有一些工作。或者，我們可能會意識到直接在我們的應用程序中使用度量標準為我們帶來了強大的好處，例如靈活的表達式?評估我們車隊的實時視圖;?相比之下，將指標納入日志管道可能會迫使我們放棄其中的一些優勢。

從這里開始，我們可以開始對現有系統進行分類。例如，Prometheus專門作為度量系統開始，隨著時間的推移可能會逐漸增加到跟蹤，從而進入請求范圍的度量標準，但可能不會過度深入到日志記錄空間。ELK提供了日志記錄和匯總，將其牢牢地置于可聚合事件空間，但似乎不斷在其他領域積累更多功能，將其推向中心。

此外，我觀察到一個奇怪的操作細節作為這種可視化的副作用。在三個域中，度量標準往往需要最少的資源來管理，因為它們的性質很好地“壓縮”。相反，伐木往往勢不可擋，往往超過其報告的生產流量。（我之前在這個主題上寫了更多。）因此，我們可以繪制一種體積或操作開銷梯度，從度量（低）到記錄（高） - 我們觀察到跟蹤可能位于中間的某個位置。

?

也許這不是對空間的完美描述，但我在峰會與會者的感覺是這種分類是有道理的：當我們所說的很清楚時，我們能夠更有成效地說話。如果您試圖了解產品空間，或者澄清您自己組織中的對話，也許這個圖對您也很有用。

原文地址：http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

參考：https://yq.aliyun.com/articles/514488?spm=a2c4e.11155435.0.0.65972a3cvBLOsg

總結

以上是生活随笔為你收集整理的度量，跟踪和日志记录的全部內容，希望文章能夠幫你解決所遇到的問題。

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