隨著支撐的內部業務系統越來越多，向著服務化架構進化，在整個迭代過程中，會逐漸暴露出以下問題。

傳統依賴于應用服務器日志等手段的排除故障原因的復雜度越來越高，傳統的監控服務已經無法滿足需求。

終端--> Nginx --> IIS --> Asp.net 管道 --> [數據緩存]->[HTTP調用]->[DB讀寫]在以上調用鏈路上，我們以往勉強能從 Nginx 日志中分析出 客戶端調用時長，Nginx 調用API服務時長。 但是到了應用程序代碼，對于[數據緩存]->[HTTP調用]->[DB讀寫]等操作，變成了鏈路調用黑盒。

在出現性能問題定位，也嚴重依賴高級工程師經驗，定位困難，指標不明確。

在分析整個應用調用鏈路，不能清晰、直觀的分析展現。

0|1度量(Metrics),跟蹤(Tracing),日志(Logging)

Logging，Metrics 和 Tracing 有各自專注的部分。

• Logging - 用于記錄離散的事件。例如，應用程序的調試信息或錯誤信息。它是我們診斷問題的依據。
  

• Metrics - 用于記錄可聚合的數據。例如，隊列的當前深度可被定義為一個度量值，在元素入隊或出隊時被更新；HTTP 請求個數可被定義為一個計數器，新請求到來時進行累加。

• Tracing - 用于記錄請求范圍內的信息。例如，一次遠程方法調用的執行過程和耗時。它是我們排查系統性能問題的利器。

詳細閱讀，參考度量(Metrics),跟蹤(Tracing),日志(Logging)

這三者的交集，才是對于我們分析應用程序運行狀態及調用鏈路分析，有這直觀重要的意義。

日志（Logging），可以使用ELK技術棧，解決我們的應用程序日志查詢分析的大部分需求。

度量(Metrics)，可以使用AppMetrics?和?Prometheus?來滿足一部分需求。

跟蹤(Tracing)，全鏈路的調用分析追蹤，目前解決方案大部分也是商業解決方案，如Application Insights、OneAPM、聽云、Datadog等，開源方案，如SkyAPM?(.net core適用)

目前，針對 .net 平臺下探針的解決方案進行調研，大部分是付費，開源方案大部分針對 .net core。

有沒有一種可能，我們使用開源技術，搭建自己的全鏈路調用分析的解決方案，這是本篇博文需要探索的議題。

我們將帶著以下幾個問題，進行探索解決方案

我們基于什么標準規范來收集指標？

出于保護企業現有投資的情況下，我們需要針對Full Framework（.net Framework、.net core）下進行支持，也可以考慮公有云應用監控。

• 代碼級定位性能問題

• 記錄應用錯誤過程

• 檢測慢SQL語句

• 檢測外部調用API耗時

• 檢測調用外部HTTP請求耗時，請求信息記錄

• 請求/RPC 調用關系拓撲

基于什么架構來搭建，有哪些組件可用，能不能達到商業解決方案的相差無幾的解決方案？

用什么的技術來實現？

跟蹤（Tracing）標準 OpenTracking

OpenTracking?為監測提供了一組標準的框架無關、廠商無關的標準規范，這意味著開發者能夠很方便的添加/切換跟蹤系統

簡單說，OpenTracking 提供了一組規范，也是分布式跟蹤系統的標準的抽象，來解決不同的分布式追蹤系統的API標準的不兼容問題。OpenTracing 是一個輕量級的標準化層，它位于應用程序/類庫和追蹤或日志分析程序之間。

更多關于 OpenTracing 數據模型的知識，請參考?OpenTracing語義標準。

技術探索

分布式追蹤系統，由追蹤器(Tracker)、追蹤信息收集代理（Agent）、追蹤信息存儲分析服務（APM Server）組成。

追蹤器(Tracker)：負責應用程序監控（代碼級別執行時間、異常調用）
追蹤信息收集代理（Agent）：負責應用程序監控信息上報
追蹤信息存儲分析服務（APM Server）：負責存儲應用程序監控信息存儲分析展示等服務

追蹤器(Tracker)

代碼埋點是實現Tracker重要一步。

如果在業務代碼中實現追蹤埋點，不但工程量大，而且代碼入侵嚴重。

var tracker = Tracker.Instance;using(var context = tracker.Begin()) { ? ?context.SetSpan("name of span"); ? ?/// some business logiccontext.EndSpan();tracker.Send(context); }

為了實現dotnet全平臺下（Framework、dotcore）追蹤，我們需要清楚C#代碼是如何變成機器可運行的代碼。

• 第一步，C# 編譯生成中間語言 IL

• 第二步，中間語言IL 通過CLR的即時編譯JIT，編譯成Native Code

我們只能通過，在CLR即時編譯 IL之前，修改已生成的IL，來實現代碼埋點。這樣以來，我們便可以輕松的實現零入侵業務代碼。

如何實現修改已生成的IL?？ 我們通過實現CLR公共語言運行時ICorProfilerCallback?中重寫JITCompilationStarted 方法即可實現。

在dotnet core 下通過DiagnosticSource 實現，應用程序性能診斷

DiagnosticSource?VS?EventSource

• EventSource，只支持Windows，主要記錄可序列化的數據，被進程意外的消費。

• DiagnosticSource，支持 .net core下，主要在進程內處理數據，可以支持非序列化的對象，比如HttpConext，HttpResponse。

• 如果在 EventSource 中獲取 DiagnosticSource 中的事件數據，可以通過 DiagnosticSourceEventSource 這個對象來進行數據橋接。

0|1Further Reading

• Apache SkyWalking 為.NET Core帶來開箱即用的分布式追蹤和應用性能監控

• 開放分布式追蹤（OpenTracing）入門與 Jaeger 實現

• 幾種分布式調用鏈監控組件的實踐與比較（一）實踐

• 在 .NET Core 中使用 DiagnosticSource 記錄跟蹤信息

• CLR公共運行時下性能分析Profiling

• .NET ClrProfiler ILRewrite實現對應用的跟蹤和分析

• .NET運行時中的監測和可觀測性?[英文版]

• Jaeger vs Apache Skywalking

• Profiling API PR

原文地址：https://www.cnblogs.com/yankliu-vip/p/how-to-implement-apm-tracer-on-dotnet.html

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的Dotnet全平台下APM-Trace探索的全部內容，希望文章能夠幫你解決所遇到的問題。

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