.NET运行时中的监测和可观测性

今年5月份的时候研究分布式追踪的问题知道了的拦截方式比较零散，刚好8月份的时候看到这篇文章，这个文章总结的比较完整。存档了很久，趁今天有空翻译给大家。原文地址，校验：张蘅水

.NET是一个托管运行时，这意味着它提供了“管理”您的程序的高级功能，从简介到公共语言运行时（CLR）（2007年编写）：

运行时具有许多功能，因此按如下方式对它们进行分类很有用：

基本功能 对其他功能设计有广泛影响的功能。这些包括：

1.垃圾收集

2.记忆安全和类型安全

3.对编程语言的高级支持。
辅助功能 - 许多有用的程序可能不需要基本特性所支持的功能：

1.使用AppDomains进行程序隔离

2.程序安全和沙盒
其他功能 - 所有运行时环境都需要但不利用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，还有其他一些方法：

上面的第二个链接讨论了在.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.

这在以下文件中实现：

另一个主要部分是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.

这些回调在以下文件中实现：

最后，值得指出的是，Profiler API可能无法在.NET Core运行的所有操作系统和CPU-arch上运行，例如Linux上的ELT调用存根问题，有关详细信息，请参阅CoreCLR Profiler API的状态。

分析和调试(Profiling v. Debugging)

除此之外，“分析”和“调试”确实有一些重叠，因此从CLR调试与CLR分析中了解.NET运行时上下文中不同的API提供了什么是有帮助的。

调试(Debugging)

调试意味着不同的事情不同的人，比如我问在Twitter上“ 什么是你调试的.NET程序的途径 ”，并得到了广泛的不同反应，虽然反应两组含有一个很好的工具清单和技术，所以他们值得一试，谢谢#LazyWeb！

但也许这句话最好总结一下Debugging究竟是什么