.NET運行時中的監測和可觀測性

今年5月份的時候研究分布式追蹤的問題知道了的攔截方式比較零散， 剛好8月份的時候看到這篇文章，這個文章總結的比較完整。存檔了很久，趁今天有空翻譯給大家。原文地址，校驗：張蘅水

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

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

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

您可以看到，“Debugging/Profiling”雖然不是基本或輔助功能，但由於“ 需要創建完整的編程環境 ” ，它仍然會進入列表。

這篇文章的其余部分將看什么 監測，可觀測性和內省功能核心CLR提供，為什么他們是有用的，如何提供他們。

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

• 診斷(Diagnostics)
  • Perf View(性能分析工具)
  • 共同基礎設施
  • 未來的計划
• 剖析(Profiling)
  • ICorProfiler API
  • 分析 v .調試
• 調試(Debugging)
  • ICorDebug API
  • SOS和DAC
  • 第三方調試器
  • 記憶轉儲

診斷(Diagnostics)

首先，我們將查看CLR提供的診斷信息，傳統上這些信息是通過“Windows事件跟蹤”（ETW）提供的。

CLR提供的各種事件涉及：

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

例如，這是觸發AppDomain Load事件的地方，這是Exception Thrown事件，這里是GC Allocation Tick事件。

Perf View

如果你想看到來自你的.NET程序的ETW事件，我建議使用優秀的PerfView工具，從這些PerfView教程開始，或者這個優秀的演講PerfView：終極.NET性能工具。PerfView被廣泛認可，因為它提供了寶貴的信息，例如Microsoft工程師經常將其用於性能調查。

共同基礎設施

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

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

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

上面的第二個鏈接討論了在.NET Core中正在使用的新“EventPipe”基礎架構（以及EventSources和EventListeners，你能發現一個主題！），你可以看到它在跨平台性能監控設計中的目標。在高層次上，它將為CLR提供一個單獨的位置來推動與診斷和性能相關的“事件”。然后，這些“事件”將被路由到一個或多個記錄器，例如，可能包括ETW，LTTng和BPF，精確記錄器由CLR運行的OS /平台確定。.NET Cross-Plat性能和事件設計中還有更多背景信息可以解釋不同日志記錄技術的優缺點。

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

未來的計划

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

控制器負責以簡單和跨平台的方式控制性能分析基礎結構和.NET性能診斷組件生成的性能數據。

我們的想法是通過從“事件管道”中提取所有相關數據，通過HTTP服務器公開以下功能：

REST API

• Pri 1：簡單分析：為運行時間配置X個時間並返回跟蹤。
• Pri 1：高級分析：開始跟蹤（以及配置）
• Pri 1：高級分析：停止跟蹤（對此調用的響應將是跟蹤本身）
• Pri 2：獲取與所有EventCounters或指定EventCounter相關的統計信息。

可瀏覽的HTML頁面

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

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

剖析(Profiling)

CLR提供的另一個強大功能是Profiling API，它（大部分）被第三方工具用於在非常低級別掛鈎到運行時。您可以在此概述中找到有關API的更多信息，但在較高級別，它允許您連接在以下情況下觸發的回調：

• GC相關事件發生
• 拋出異常
• 裝配/卸載裝配
• 更多，更多

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

此外還有其他非常強大的功能。首先，您可以設置每次執行.NET方法時調用的掛鈎，無論是在運行時還是用戶代碼中。這些回調被稱為“進入/離開”鈎子，並且有一個很好的示例顯示如何使用它們，但為了使它們工作，您需要了解不同操作系統和CPU架構的“調用約定”，這並不總是容易的。另外，作為警告，Profiling API是一個只能通過C / C ++代碼訪問的COM組件，你不能在C＃/ F＃/ VB.NET中使用它！

其次，Profiler能夠通過SetILFunctionBody（）API在JIT 之前重寫任何.NET方法的IL代碼。這個API功能非常強大，構成了許多.NET APM工具的基礎，您可以在我之前的文章中了解更多關於如何使用它的方法。如何模擬密封類和靜態方法以及隨附的代碼。

ICorProfiler API

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

所有Profiling API接口和回調的總體定義可在\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.

這在以下文件中實現：

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

另一個主要部分是EE - > Profiler回調，它們在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.

這些回調在以下文件中實現：

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

最后，值得指出的是，Profiler API可能無法在.NET Core運行的所有操作系統和CPU-arch上運行，例如Linux上的ELT調用存根問題，有關詳細信息，請參閱CoreCLR Profiler API的狀態。

分析和調試(Profiling v. Debugging)

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

調試(Debugging)

調試意味着不同的事情不同的人，比如我問在Twitter上“ 什么是你調試的.NET程序的途徑 ”，並得到了廣泛的不同反應，雖然反應兩組含有一個很好的工具清單和技術，所以他們值得一試，謝謝#LazyWeb！

但也許這句話最好總結一下Debugging究竟是什么😊

CLR提供了與調試相關的非常廣泛的功能，但為什么需要提供這些服務，優秀的帖子為什么托管調試與本機調試不同？提供了3個理由：

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

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

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

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

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

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

在一個完美的世界中，每個人都會使用ICorDebug我們的公共調試API。但是，像您這樣的工具開發人員所需的絕大多數功能都缺乏ICorDebug。這是我們正在修復的問題，但這些改進將進入CLR v.next，而不是舊版本的CLR。實際上，ICorDebugAPI僅在CLR v4中添加了對故障轉儲調試的支持。任何調試CLR v2崩潰轉儲的人根本無法使用ICorDebug！

（有關其他文章，請參閱SOS和ICorDebug）

該ICorDebugAPI實際上是分成多個接口，也有在他們的70！我不會在這里列出所有內容，但是我將展示它們所屬的類別，有關更多信息，請參閱ICorDebug的分區，其中包含此列表，因為它更詳細。

• 頂級(Debugging)： ICorDebug + ICorDebug2是頂級接口，有效地充當ICorDebugProcess對象的集合。
• 回調(Callbacks)：通過調試器實現的回調對象上的方法調度托管調試事件
• 進程(Process)：這組接口表示正在運行的代碼，並包含與事件相關的API。
• 代碼/類型檢查(Code / Type Inspection)： 主要可以在靜態PE映像上運行，但實時數據有一些便​​捷方法。
• 執行控制(Execution Control)：執行是“檢查”線程執行的能力。實際上，這意味着放置斷點（F9）和踩踏（F11步入，F10步進，S + F11步出）等。ICorDebug的執行控制僅在托管代碼中運行。
• 線程+調用堆棧(Threads + Callstacks)：調用堆棧是調試器檢查功能的支柱。以下接口與獲取callstack有關。ICorDebug僅公開調試托管代碼，因此堆棧跟蹤僅受管理。
• 對象檢查(Object Inspection)：對象檢查是API的一部分，它允許您在整個調試對象中查看變量的值。對於每個接口，我列出了“MVP”方法，我認為必須簡潔地傳達該接口的用途。

另外需要注意的是，與Profiling APIs一樣，調試API的支持級別因操作系統和CPU架構而異。例如，截至2018年8月，“沒有針對Linux ARM進行托管調試和診斷的解決方案”。有關“Linux”支持的更多信息，請參閱這篇很棒的文章，在Linux上使用LLDB調試.NET Core，並從Microsoft 檢出診斷存儲庫，其目標是更容易在Linux上調試.NET程序。

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

SOS和DAC

“數據訪問組件(Data Access Component)”（DAC）在BOTR頁面中有詳細討論，但實際上它提供了對CLR數據結構的“進程外”訪問，因此可以從另一個進程讀取其內部詳細信息。這允許調試器（via ICorDebug）或'Son of Strike'（SOS）擴展進入CLR的運行實例或內存轉儲，並找到如下內容：

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

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

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

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

這是代碼流，顯示了SOS和DAC如何協同工作：

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

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

由於Microsoft發布了調試API，它允許第三方使用ICorDebug接口，這里列出了我遇到的一些內容：

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

記憶轉儲(Memory Dumps)

我們要看的最后一個區域是“內存轉儲”，可以從實時系統中捕獲並離線分析。.NET運行時一直很好地支持在Windows上創建“內存轉儲”，現在.NET Core是“跨平台”，也可以在其他操作系統上使用相同的工具。

“內存轉儲”的一個問題是，獲取SOS和DAC文件的正確匹配版本可能會非常棘手。幸運的是，Microsoft剛剛發布了以下dotnet symbolCLI工具：

可以下載任何給定核心轉儲，minidump或任何支持平台的文件格式（如ELF，MachO，Windows DLL，PDB和便攜式PDB）的調試所需的所有文件（給出coreclr模塊的符號，模塊，SOS和DAC）。

最后，如果你花費任何時間分析'內存轉儲'，你真的應該看看微軟幾年前發布的優秀的CLR MD庫。我之前已經寫過你可以用它做什么，但簡而言之，它允許你通過一個直觀的C＃API與內存轉儲交互，其中的類可以訪問ClrHeap，GC Roots，CLR Threads，Stack Frames和更多。實際上，除了實現工作所需的時間之外，CLR MD還可以實現大多數（如果不是全部）SOS命令。

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

ClrMD托管庫是CLR僅內部調試API的包裝器。雖然這些僅內部API對於診斷非常有用，但我們不支持它們作為公開的，有文檔的版本，因為它們非常難以使用並且與CLR的其他實現細節緊密耦合。ClrMD通過圍繞這些低級調試API提供易於使用的托管包裝來解決此問題。

通過在官方支持的庫中提供這些API，Microsoft使開發人員能夠在CLRMD之上構建各種工具，這是一個很好的結果！

---

總而言之，.NET Runtime提供了廣泛的診斷，調試和分析功能，可以深入了解CLR內部的情況。