本文從 [場景/概念/定義]，演變的統一規範，再到滋生出的各類開源產品，產品的接入，應用案例等的闡述。

涉及到的元件及版本：.NET 6，OpenTelemetry v1.6，SkyWalking v8.9.1，Jaeger v1.51，Prometheus v2.48

一、概念及定義

1.1 面臨的場景

現代網際網路服務通常被開發成複雜的、大規模的分散式系統。在分散式系統中，一次外部請求往往需要內部多個模組，多箇中介軟體，多臺機器或第三方等相互呼叫才能完成。在這一完整的呼叫過程中，有序列執行的，也有並行執行的，有關業務走向的，有關處理能力的等等。

  隨著微服務和雲原生開發的興起，越來越多應用基於分散式進行開發，但是大型應用拆分為微服務後，服務之間的依賴和呼叫變得越來越複雜，這些服務是由不同團隊開發的軟體模組集合構建的，可能使用不同的程式語言，並且可能跨越多個物理設施中的數千臺機器，他們之間提供的介面可能不同(RPC/API等)。在這種情況下，我們如何才能快速的確定某次請求都呼叫了哪些應用？哪些模組？哪些節點？以及它們的先後順序及各部分的效能如何呢？

1.2 Observability

Observability 可觀測性是指如何通過檢查系統的執行資料，來了解系統的內部狀態。它從各種來源收集和分析資料，以針對環境中執行的應用程式的行為提供詳細見解。它可以應用於任何您構建的並希望進行監測的系統。

  可觀測性很重要的原因在於 [發現]，藉助可觀測性，可讓軟體工程師、IT、DevOps 和專案團隊解讀遙測資料。藉助儀表板、服務依賴關係圖和分散式跟蹤等視覺化功能，甚至 AI 和機器學習方法，輕鬆完成。有了合適的可觀測性解決方案，就可以瞭解應用程式、服務和基礎架構在跟蹤和響應問題方面的表現。讓團隊評估、監測和改進分散式 IT 系統的效能。甚至可以主動診斷、分析問題，並追溯問題根源。 

1.3 應用程式效能監控

Application Performance Monitoring (APM)，觀測的一種方式，可觀測性的子集。APM 解決方案可收集和監測來自各種網站、軟體應用程式和服務的遙測資料，並對資料進行分析。是組織快速識別和解決應用程式和程式碼中任何效能問題的過程。

  APM 會使用一套工具和方法來監測和管理軟體應用程式的效能。APM 工具一般包括對關鍵指標的監測，以此來識別和診斷效能瓶頸和問題。一些關鍵的指標例舉：請求率/錯誤率/響應時間/服務範例數/硬體利用率等。設定各指標的範圍(如記憶體剩餘低於20%時)，做出響應告警。
如下圖監控指標範例：

  APM 還可以提供詳細的分散式鏈路追蹤和故障排查資訊，也是解決以上面臨的場景提出來的問題，將每次分散式請求過程中的每個環節的執行情況，按序/耗時/狀態/並串型等，很直觀的集中展示出來。協助開發人員瞭解和修復程式碼中的問題，快速排查及隱患及預估處理能力等。這通常包括告警和報告功能，以讓相關方始終了解應用程式的效能。這種多個節點串聯起來的請求過程稱為 Tracing。
如下圖所示的 Trace、Span、Time 關係圖：

Tracing 鏈路追蹤是一種用於分析和監視應用程式的方法，尤其是那些使用微服務體系結構構建的分散式的應用程式。一個完整請求鏈路的追蹤(TraceID)用於查出本次請求呼叫的所有服務/介面/元件等，呼叫的每個服務/介面/元件等都被稱為跨度(Span)，用來記錄呼叫順序，上游跨度(ParenetID)用來記錄呼叫的層級關係。呼叫時間週期Timestamp，是把請求發出、接收、處理的時間都記錄下來。跨度還可以記錄一些其它屬性資訊，比如發起呼叫服務名稱、被調服務名稱、返回結果、IP、請求狀態、紀錄檔、故障等。最後再把擁有相同(TraceID)的跨度(Span)合成一個更大範圍的試圖，就形成了一個完整的單次請求呼叫鏈。

通過以上提到的 [監控] [鏈路]，APM 能夠對應用程式的執行情況提供連續不斷的詳細見解。團隊可以利用這些見解，更加積極主動地解決問題，而不是等到客戶投訴了才有所行動。APM 有多種用途。例如，團隊可以針對使用者體驗過程中的效能下降設定告警，衡量最新版本的影響，並就哪些地方需要改進做出明智的決策。

總結起來，它可以使得我們發現很多不曾注意到的細節，發現隱蔽的迴圈依賴，及早的發現問題，定位問題，優化改進，也可以幫助新人理解業務等等。

作者：[Sol·wang] - 部落格園，原文出處：https://www.cnblogs.com/Sol-wang/

二、發展及產品

2.1 最初概念

從最初 Google 公司在 Dapper 中提到的 trace、span、annotation 概念：

• Trace：一次完整的分散式呼叫跟蹤鏈路；
• Span：跨服務的一次呼叫，多個Span組合成一次Trace記錄；
• Annotation：用來記錄請求特定事件的相關詳細資訊及補充；

但 Google-Dapper 並沒有開源，它是 Google 內部長期經過打磨後形成的產品，於2010年公佈，對外是一篇論文，講述的是分散式鏈路追蹤的理論和 Dapper 的設計思想。大致由 [植入應用、收集跟蹤資料、圖形化UI] 三部分組成。後續市場的發展，有很多鏈路追蹤系統也是基於 Dapper 論文的思想和理論為基礎的。個人覺得 Google-Dapper 實現了兩大方面：監控(發現細微的變化)、跟蹤(及時定位並處理)。

2.2 統一規範

於2016年開始的 OpenTracing 專案得到絕大多數相關團隊的認可，為分散式追蹤，提供統一的概念、規範和介面。它是一個輕量級的標準化層，並不是功能實現程式碼，它只是為跟蹤資料，用程式碼定義了一套資料模型，和一套API，是供統一遵循的規範，用於在應用程式中建立和管理這些資料模型。現在大多數鏈路跟蹤產品系統都在儘量相容遵循 OpenTracing 設計原則。