隨著支撐的內(nèi)部業(yè)務(wù)系統(tǒng)越來越多，向著服務(wù)化架構(gòu)進(jìn)化，在整個迭代過程中，會逐漸暴露出以下問題。

傳統(tǒng)依賴于應(yīng)用服務(wù)器日志等手段的排除故障原因的復(fù)雜度越來越高，傳統(tǒng)的監(jiān)控服務(wù)已經(jīng)無法滿足需求。

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

在出現(xiàn)性能問題定位，也嚴(yán)重依賴高級工程師經(jīng)驗，定位困難，指標(biāo)不明確。

在分析整個應(yīng)用調(diào)用鏈路，不能清晰、直觀的分析展現(xiàn)。

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

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

• Logging - 用于記錄離散的事件。例如，應(yīng)用程序的調(diào)試信息或錯誤信息。它是我們診斷問題的依據(jù)。
  

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

• Tracing - 用于記錄請求范圍內(nèi)的信息。例如，一次遠(yuǎn)程方法調(diào)用的執(zhí)行過程和耗時。它是我們排查系統(tǒng)性能問題的利器。

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

這三者的交集，才是對于我們分析應(yīng)用程序運行狀態(tài)及調(diào)用鏈路分析，有這直觀重要的意義。

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

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

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

目前，針對 .net 平臺下探針的解決方案進(jìn)行調(diào)研，大部分是付費，開源方案大部分針對 .net core。

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

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

我們基于什么標(biāo)準(zhǔn)規(guī)范來收集指標(biāo)？

出于保護(hù)企業(yè)現(xiàn)有投資的情況下，我們需要針對Full Framework（.net Framework、.net core）下進(jìn)行支持，也可以考慮公有云應(yīng)用監(jiān)控。

• 代碼級定位性能問題

• 記錄應(yīng)用錯誤過程

• 檢測慢SQL語句

• 檢測外部調(diào)用API耗時

• 檢測調(diào)用外部HTTP請求耗時，請求信息記錄

• 請求/RPC 調(diào)用關(guān)系拓?fù)?/p>

基于什么架構(gòu)來搭建，有哪些組件可用，能不能達(dá)到商業(yè)解決方案的相差無幾的解決方案？

用什么的技術(shù)來實現(xiàn)？

跟蹤（Tracing）標(biāo)準(zhǔn) OpenTracking

OpenTracking?為監(jiān)測提供了一組標(biāo)準(zhǔn)的框架無關(guān)、廠商無關(guān)的標(biāo)準(zhǔn)規(guī)范，這意味著開發(fā)者能夠很方便的添加/切換跟蹤系統(tǒng)

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

更多關(guān)于 OpenTracing 數(shù)據(jù)模型的知識，請參考?OpenTracing語義標(biāo)準(zhǔn)。

技術(shù)探索

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

追蹤器(Tracker)：負(fù)責(zé)應(yīng)用程序監(jiān)控（代碼級別執(zhí)行時間、異常調(diào)用）
追蹤信息收集代理（Agent）：負(fù)責(zé)應(yīng)用程序監(jiān)控信息上報
追蹤信息存儲分析服務(wù)（APM Server）：負(fù)責(zé)存儲應(yīng)用程序監(jiān)控信息存儲分析展示等服務(wù)

追蹤器(Tracker)

代碼埋點是實現(xiàn)Tracker重要一步。

如果在業(yè)務(wù)代碼中實現(xiàn)追蹤埋點，不但工程量大，而且代碼入侵嚴(yán)重。

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

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

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

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

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

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

在dotnet core 下通過DiagnosticSource 實現(xiàn)，應(yīng)用程序性能診斷

DiagnosticSource?VS?EventSource

• EventSource，只支持Windows，主要記錄可序列化的數(shù)據(jù)，被進(jìn)程意外的消費。

• DiagnosticSource，支持 .net core下，主要在進(jìn)程內(nèi)處理數(shù)據(jù)，可以支持非序列化的對象，比如HttpConext，HttpResponse。

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

0|1Further Reading

• Apache SkyWalking 為.NET Core帶來開箱即用的分布式追蹤和應(yīng)用性能監(jiān)控

• 開放分布式追蹤（OpenTracing）入門與 Jaeger 實現(xiàn)

• 幾種分布式調(diào)用鏈監(jiān)控組件的實踐與比較（一）實踐

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

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

• .NET ClrProfiler ILRewrite實現(xiàn)對應(yīng)用的跟蹤和分析

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

• Jaeger vs Apache Skywalking

• Profiling API PR

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。