今年5月份的時候研究分布式追蹤的問題知道了的攔截方式比較零散褥符， 剛好8月份的時候看到這篇文章鹃操，這邊文章總結(jié)的比較完整韭寸。好久都沒有翻譯，趁今天有空翻譯給大家荆隘。原文地址恩伺，校驗：張蘅水

.NET是一個托管運行時，這意味著它提供了“管理”您的程序的高級功能椰拒，從簡介到公共語言運行時（CLR）（2007年編寫）：

運行時具有許多功能晶渠，因此按如下方式對它們進行分類很有用：

1. 基本功能 對其他功能設(shè)計有廣泛影響的功能。這些包括：
   1.垃圾收集
   2.記憶安全和類型安全
   3.對編程語言的高級支持耸三。
2. 輔助功能 - 許多有用的程序可能不需要基本特性所支持的功能：
   1.使用AppDomains進行程序隔離
   2.程序安全和沙盒
3. 其他功能 - 所有運行時環(huán)境都需要但不利用CLR基本功能的功能乱陡。相反，它們是創(chuàng)建完整編程環(huán)境的結(jié)果仪壮。其中包括：
   1.版本
   2.Debugging/Profiling
   3.互操作

您可以看到憨颠，“Debugging/Profiling”雖然不是基本或輔助功能，但由于“ 需要創(chuàng)建完整的編程環(huán)境 ” 积锅，它仍然會進入列表爽彤。

這篇文章的其余部分將看什么 監(jiān)測，可觀測性和內(nèi)省功能核心CLR提供缚陷，為什么他們是有用的适篙，如何提供他們。**

為了便于瀏覽箫爷，帖子分為3個主要部分（最后有一些“額外閱讀材料”）：

• 診斷(Diagnostics)
  • Perf View(性能分析工具)
  • 共同基礎(chǔ)設(shè)施
  • 未來的計劃
• 剖析(Profiling)
  • ICorProfiler API
  • 分析 v .調(diào)試
• 調(diào)試(Debugging)
  • ICorDebug API
  • SOS和DAC
  • 第三方調(diào)試器
  • 記憶轉(zhuǎn)儲

診斷(Diagnostics)

首先嚷节，我們將查看CLR提供的診斷信息聂儒，傳統(tǒng)上這些信息是通過“Windows事件跟蹤”（ETW）提供的。

CLR提供的各種事件涉及：

• 垃圾收集（GC）
• 即時（JIT）編譯
• 模塊和AppDomains
• 線程和鎖爭用
• 以及更多

例如硫痰，這是觸發(fā)AppDomain Load事件的地方衩婚，這是Exception Thrown事件，這里是GC Allocation Tick事件效斑。

Perf View

如果你想看到來自你的.NET程序的ETW事件非春，我建議使用優(yōu)秀的PerfView工具，從這些PerfView教程開始缓屠，或者這個優(yōu)秀的演講PerfView：終極.NET性能工具奇昙。PerfView被廣泛認可，因為它提供了寶貴的信息敌完，例如Microsoft工程師經(jīng)常將其用于性能調(diào)查储耐。

image.png

共同基礎(chǔ)設(shè)施

但是，如果從名稱中不清楚滨溉，ETW事件僅在Windows上可用弧岳，這并不適合新的.NET“跨平臺”世界。您可以在Linux上使用PerfView進行性能跟蹤（通過LTTng）业踏，但這只是cmd-line集合工具禽炬，稱為“PerfCollect”，分析和豐富的UI（包括flamegraphs）目前僅適用于Windows勤家。

但是如果你想分析.NET Performance Linux腹尖，還有其他一些方法：

• 在Linux上使用.NET Core獲取LTTng事件的堆棧
• Linux性能問題

上面的第二個鏈接討論了在.NET Core中正在使用的新“EventPipe”基礎(chǔ)架構(gòu)（以及EventSources和EventListeners，你能發(fā)現(xiàn)一個主題７ゲ薄）热幔，你可以看到它在跨平臺性能監(jiān)控設(shè)計中的目標(biāo)。在高層次上讼庇，它將為CLR提供一個單獨的位置來推動與診斷和性能相關(guān)的“事件”绎巨。然后，這些“事件”將被路由到一個或多個記錄器蠕啄，例如场勤，可能包括ETW，LTTng和BPF歼跟，精確記錄器由CLR運行的OS /平臺確定和媳。.NET Cross-Plat性能和事件設(shè)計中還有更多背景信息可以解釋不同日志記錄技術(shù)的優(yōu)缺點。

“事件管道”中正在進行的所有工作都在“性能監(jiān)控”項目和相關(guān)的“EventPipe”問題中進行跟蹤哈街。

未來的計劃

最后留瞳，還有一個性能分析控制器的(Performance Profiling Controller )未來計劃，其目標(biāo)如下：

控制器負責(zé)以簡單和跨平臺的方式控制性能分析基礎(chǔ)結(jié)構(gòu)和.NET性能診斷組件生成的性能數(shù)據(jù)骚秦。

我們的想法是通過從“事件管道”中提取所有相關(guān)數(shù)據(jù)她倘，通過HTTP服務(wù)器公開以下功能：

REST API

• Pri 1：簡單分析：為運行時間配置X個時間并返回跟蹤璧微。
• Pri 1：高級分析：開始跟蹤（以及配置）
• Pri 1：高級分析：停止跟蹤（對此調(diào)用的響應(yīng)將是跟蹤本身）
• Pri 2：獲取與所有EventCounters或指定EventCounter相關(guān)的統(tǒng)計信息。

可瀏覽的HTML頁面

• Pri 1：流程中所有托管代碼堆棧的文本表示硬梁。
• 提供當(dāng)前正在運行的用作簡單診斷報告的快照概述往毡。
• Pri 2：顯示EventCounters的當(dāng)前狀態(tài)（可能具有歷史記錄）。
• 提供現(xiàn)有計數(shù)器及其值的概述靶溜。
• 開放性問題：我不相信存在必要的公共API來枚舉EventCounters。

我很高興看到“性能分析控制器(Performance Profiling Controller)”（PPC懒震？）的位置罩息，我認為將這種內(nèi)置到CLR中確實非常有價值，這是其他運行時的內(nèi)容个扰。

剖析(Profiling)

CLR提供的另一個強大功能是Profiling API瓷炮，它（大部分）被第三方工具用于在非常低級別掛鉤到運行時。您可以在此概述中找到有關(guān)API的更多信息递宅，但在較高級別娘香，它允許您連接在以下情況下觸發(fā)的回調(diào)：

• GC相關(guān)事件發(fā)生
• 拋出異常
• 裝配/卸載裝配
• 更多，更多

image.png

來自BOTR頁面的圖像分析API - 概述

此外還有其他非常強大的功能办龄。首先烘绽，您可以設(shè)置每次執(zhí)行.NET方法時調(diào)用的掛鉤，無論是在運行時還是用戶代碼中俐填。這些回調(diào)被稱為“進入/離開”鉤子安接，并且有一個很好的示例顯示如何使用它們，但為了使它們工作英融，您需要了解不同操作系統(tǒng)和CPU架構(gòu)的“調(diào)用約定”盏檐，這并不總是容易的。另外驶悟，作為警告胡野，Profiling API是一個只能通過C / C ++代碼訪問的COM組件，你不能在C＃/ F＃/ VB.NET中使用它痕鳍！

其次硫豆，Profiler能夠通過SetILFunctionBody（）API在JIT 之前重寫任何.NET方法的IL代碼。這個API功能非常強大笼呆，構(gòu)成了許多.NET APM工具的基礎(chǔ)够庙，您可以在我之前的文章中了解更多關(guān)于如何使用它的方法。如何模擬密封類和靜態(tài)方法以及隨附的代碼抄邀。

ICorProfiler API

事實證明耘眨，運行時必須執(zhí)行各種瘋狂的技巧才能使Profiling API正常工作，只需查看進入此PR的內(nèi)容允許重新連接（有關(guān)'ReJIT'的詳細信息境肾，請參閱ReJIT：A How-To指南）剔难。

所有Profiling API接口和回調(diào)的總體定義可在\vm\inc\corprof.idl中找到（請參閱接口說明語言）胆屿。但它分為2個邏輯部分，一個是Profiler - >'Execution Engine'（EE）接口偶宫，稱為ICorProfilerInfo：

// Declaration of class that implements the ICorProfilerInfo* interfaces, which allow the
// Profiler to communicate with the EE.  This allows the Profiler DLL to get
// access to private EE data structures and other things that should never be exported
// outside of the EE.

這在以下文件中實現(xiàn)：

• \VM\proftoeeinterfaceimpl.h
• \VM\proftoeeinterfaceimpl.inl
• \VM\proftoeeinterfaceimpl.cpp

另一個主要部分是EE - > Profiler回調(diào)非迹，它們在ICorProfilerCallback界面下組合在一起：

// This module implements wrappers around calling the profiler's 
// ICorProfilerCallaback* interfaces. When code in the EE needs to call the
// profiler, it goes through EEToProfInterfaceImpl to do so.

這些回調(diào)在以下文件中實現(xiàn)：

• VM\eetoprofinterfaceimpl.h
• VM\eetoprofinterfaceimpl.inl
• VM\eetoprofinterfaceimpl.cpp
• VM\eetoprofinterfacewrapper.inl

最后，值得指出的是纯趋，Profiler API可能無法在.NET Core運行的所有操作系統(tǒng)和CPU-arch上運行憎兽，例如Linux上的ELT調(diào)用存根問題，有關(guān)詳細信息吵冒，請參閱CoreCLR Profiler API的狀態(tài)纯命。

分析和調(diào)試(Profiling v. Debugging)

除此之外，“分析”和“調(diào)試”確實有一些重疊痹栖，因此從CLR調(diào)試與CLR分析中了解.NET運行時上下文中不同的API提供了什么是有幫助的亿汞。

image.png

調(diào)試(Debugging)

調(diào)試意味著不同的事情不同的人，比如我問在Twitter上“ 什么是你調(diào)試的.NET程序的途徑 ”揪阿，并得到了廣泛的不同反應(yīng)疗我，雖然反應(yīng)兩組含有一個很好的工具清單和技術(shù)，所以他們值得一試南捂，謝謝#LazyWeb吴裤！

但也許這句話最好總結(jié)一下Debugging究竟是什么??

image.png

CLR提供了與調(diào)試相關(guān)的非常廣泛的功能，但為什么需要提供這些服務(wù)溺健，優(yōu)秀的帖子為什么托管調(diào)試與本機調(diào)試不同嚼摩？提供了3個理由：

1. 可以在硬件級別抽象本機調(diào)試，但需要在IL級別抽象管理調(diào)試
2. 托管調(diào)試需要大量的信息矿瘦，直到運行時才可用
3. 托管調(diào)試器需要與垃圾收集器（GC）協(xié)調(diào)

所以給一個體面的經(jīng)驗枕面，CLR 具有提供更高級別的調(diào)試API稱ICorDebug，這將在下面從“常用的調(diào)試方案”的圖像中顯示的BOTR：

image.png

此外缚去，還有很好的描述了不同部分如何在管理斷點如何工作中相互作用潮秘？，雖然描述左和右是上圖中的相反易结！

Here’s an overview of the pipeline of components:
1) End-user
2) Debugger (such as Visual Studio or MDbg).
3) CLR Debugging Services (which we call "The Right Side"). This is the implementation of ICorDebug (in mscordbi.dll).
---- process boundary between Debugger and Debuggee ----
4) CLR. This is mscorwks.dll. This contains the in-process portion of the debugging services (which we call "The Left Side") which communicates directly with the RS in stage #3.
5) Debuggee's code (such as end users C# program)

ICorDebug API

但是如何實現(xiàn)所有這些以及從CLR Debugging簡要介紹的不同組件是什么：

所有.Net調(diào)試支持都在我們稱之為“The Dac”的dll之上實現(xiàn)枕荞。此文件（通常命名mscordacwks.dll）是我們的公共調(diào)試API（ICorDebug）以及兩個私有調(diào)試API 的構(gòu)建塊：SOS-Dac API和IXCLR。

在一個完美的世界中搞动，每個人都會使用ICorDebug我們的公共調(diào)試API躏精。但是，像您這樣的工具開發(fā)人員所需的絕大多數(shù)功能都缺乏ICorDebug鹦肿。這是我們正在修復(fù)的問題矗烛，但這些改進將進入CLR v.next，而不是舊版本的CLR箩溃。實際上瞭吃，ICorDebugAPI僅在CLR v4中添加了對故障轉(zhuǎn)儲調(diào)試的支持碌嘀。任何調(diào)試CLR v2崩潰轉(zhuǎn)儲的人根本無法使用ICorDebug！

（有關(guān)其他文章歪架，請參閱SOS和ICorDebug）

該ICorDebugAPI實際上是分成多個接口股冗，也有在他們的70！我不會在這里列出所有內(nèi)容和蚪，但是我將展示它們所屬的類別止状，有關(guān)更多信息，請參閱ICorDebug的分區(qū)攒霹，其中包含此列表怯疤，因為它更詳細。

• 頂級(Debugging)： ICorDebug + ICorDebug2是頂級接口剔蹋，有效地充當(dāng)ICorDebugProcess對象的集合。
• 回調(diào)(Callbacks)：通過調(diào)試器實現(xiàn)的回調(diào)對象上的方法調(diào)度托管調(diào)試事件
• 進程(Process)：這組接口表示正在運行的代碼辅髓，并包含與事件相關(guān)的API泣崩。
• 代碼/類型檢查(Code / Type Inspection)： 主要可以在靜態(tài)PE映像上運行，但實時數(shù)據(jù)有一些便??捷方法洛口。
• 執(zhí)行控制(Execution Control)：執(zhí)行是“檢查”線程執(zhí)行的能力矫付。實際上，這意味著放置斷點（F9）和踩踏（F11步入第焰，F(xiàn)10步進买优，S + F11步出）等。ICorDebug的執(zhí)行控制僅在托管代碼中運行挺举。
• 線程+調(diào)用堆棧(Threads + Callstacks)：調(diào)用堆棧是調(diào)試器檢查功能的支柱杀赢。以下接口與獲取callstack有關(guān)。ICorDebug僅公開調(diào)試托管代碼湘纵，因此堆棧跟蹤僅受管理脂崔。
• 對象檢查(Object Inspection)：對象檢查是API的一部分，它允許您在整個調(diào)試對象中查看變量的值梧喷。對于每個接口砌左，我列出了“MVP”方法，我認為必須簡潔地傳達該接口的用途铺敌。

另外需要注意的是汇歹，與Profiling APIs一樣，調(diào)試API的支持級別因操作系統(tǒng)和CPU架構(gòu)而異偿凭。例如产弹，截至2018年8月，“沒有針對Linux ARM進行托管調(diào)試和診斷的解決方案”弯囊。有關(guān)“Linux”支持的更多信息取视，請參閱這篇很棒的文章硝皂，在Linux上使用LLDB調(diào)試.NET Core，并從Microsoft 檢出診斷存儲庫作谭，其目標(biāo)是更容易在Linux上調(diào)試.NET程序稽物。

最后，如果你想看看ICorDebugAPI在C＃中的樣子折欠，看一下CLRMD庫中包含的包裝器贝或，包括所有可用的回調(diào)（CLRMD將在后面的文章中進行更深入的介紹）。

SOS和DAC

“數(shù)據(jù)訪問組件(Data Access Component)”（DAC）在BOTR頁面中有詳細討論锐秦，但實際上它提供了對CLR數(shù)據(jù)結(jié)構(gòu)的“進程外”訪問咪奖，因此可以從另一個進程讀取其內(nèi)部詳細信息。這允許調(diào)試器（via ICorDebug）或'Son of Strike'（SOS）擴展進入CLR的運行實例或內(nèi)存轉(zhuǎn)儲酱床，并找到如下內(nèi)容：

• 所有正在運行的線程
• 托管堆上有哪些對象
• 有關(guān)方法的完整信息羊赵，包括機器代碼
• 當(dāng)前的'堆棧跟蹤'

除此之外，如果您想要解釋所有奇怪的名稱和一點'.NET歷史課'扇谣，請參閱此Stack Overflow答案昧捷。

SOS命令的完整列表非常令人印象深刻，并且在WinDBG旁邊使用它可以讓您非常低級地了解程序和CLR中發(fā)生的情況罐寨。要了解它是如何實現(xiàn)的靡挥，讓我們看一下這個!HeapStat命令，該命令可以為您提供.NET GC正在使用的不同堆大小的摘要：

image.png

（來自SOS的圖片：即將發(fā)布的版本有一些新命令 - HeapStat）

這是代碼流鸯绿，顯示了SOS和DAC如何協(xié)同工作：

• SOS完整!HeapStat命令（鏈接）
• SOS!HeapStat處理'Workstation GC' 的命令中的代碼（鏈接）
• SOS GCHeapUsageStats(..)功能跋破，重負荷（鏈接）
• 共享DacpGcHeapDetails包含指向GC堆中主數(shù)據(jù)的指針的數(shù)據(jù)結(jié)構(gòu)，例如段瓶蝴，卡表和各代（鏈接）
• GetGCHeapStaticData填充DacpGcHeapDetails結(jié)構(gòu)的DAC函數(shù)（鏈接）
• 共享DacpHeapSegmentData包含GC堆的單個“段”的詳細信息的數(shù)據(jù)結(jié)構(gòu)（鏈接）
• GetHeapSegmentData(..)填充DacpHeapSegmentData結(jié)構(gòu)的DAC（鏈接）

第三方'調(diào)試器'(3rd Party ‘Debuggers’)

由于Microsoft發(fā)布了調(diào)試API毒返，它允許第三方使用ICorDebug接口，這里列出了我遇到的一些內(nèi)容：

• 調(diào)試器.NET Core運行時來自三星
  • 調(diào)試器提供GDB / MI或VSCode調(diào)試適配器接口舷手，并允許在.NET Core運行時下調(diào)試.NET應(yīng)用程序饿悬。
  • 可能是他們將.NET Core移植到他們的Tizen OS的工作的一部分
• dnSpy - “.NET調(diào)試器和匯編編輯器”
  • 一個非常令人印象深刻的工具，它是一個'調(diào)試器'聚霜，'匯編編輯器'狡恬，'十六進制編輯器'，'反編譯器'等等蝎宇！
• MDbg.exe（.NET Framework命令行調(diào)試程序）
  • 可以作為NuGet包和GitHub存儲庫使用弟劲，也可以從Microsoft下載。
  • 但是姥芥，目前MDBG似乎不適用于.NET Core兔乞，請參閱端口MDBG到CoreCLR和ETA以將mdbg移植到coreclr以獲取更多信息。
• JetBrains'Rider'允許在Windows上進行.NET Core調(diào)試
  • 雖然由于許可問題引起了一些爭議
  • 有關(guān)更多信息，請參閱此HackerNews主題

記憶轉(zhuǎn)儲(Memory Dumps)

我們要看的最后一個區(qū)域是“內(nèi)存轉(zhuǎn)儲”庸追，可以從實時系統(tǒng)中捕獲并離線分析霍骄。.NET運行時一直很好地支持在Windows上創(chuàng)建“內(nèi)存轉(zhuǎn)儲”，現(xiàn)在.NET Core是“跨平臺”淡溯，也可以在其他操作系統(tǒng)上使用相同的工具读整。

“內(nèi)存轉(zhuǎn)儲”的一個問題是，獲取SOS和DAC文件的正確匹配版本可能會非常棘手咱娶。幸運的是米间，Microsoft剛剛發(fā)布了以下dotnet symbolCLI工具：

可以下載任何給定核心轉(zhuǎn)儲，minidump或任何支持平臺的文件格式（如ELF膘侮，MachO屈糊，Windows DLL，PDB和便攜式PDB）的調(diào)試所需的所有文件（給出coreclr模塊的符號琼了，模塊逻锐，SOS和DAC）。

最后雕薪，如果你花費任何時間分析'內(nèi)存轉(zhuǎn)儲'昧诱，你真的應(yīng)該看看微軟幾年前發(fā)布的優(yōu)秀的CLR MD庫。我之前已經(jīng)寫過你可以用它做什么蹦哼，但簡而言之鳄哭，它允許你通過一個直觀的C＃API與內(nèi)存轉(zhuǎn)儲交互要糊，其中的類可以訪問ClrHeap纲熏，GC Roots，CLR Threads锄俄，Stack Frames和更多局劲。實際上，除了實現(xiàn)工作所需的時間之外奶赠，CLR MD還可以實現(xiàn)大多數(shù)（如果不是全部）SOS命令鱼填。

但是從宣布帖子來看它是如何運作的：

ClrMD托管庫是CLR僅內(nèi)部調(diào)試API的包裝器。雖然這些僅內(nèi)部API對于診斷非常有用毅戈，但我們不支持它們作為公開的苹丸，有文檔的版本，因為它們非常難以使用并且與CLR的其他實現(xiàn)細節(jié)緊密耦合苇经。ClrMD通過圍繞這些低級調(diào)試API提供易于使用的托管包裝來解決此問題赘理。

通過在官方支持的庫中提供這些API，Microsoft使開發(fā)人員能夠在CLRMD之上構(gòu)建各種工具扇单，這是一個很好的結(jié)果商模！

總而言之，.NET Runtime提供了廣泛的診斷，調(diào)試和分析功能施流，可以深入了解CLR內(nèi)部的情況响疚。