prometheus-net.DotNetRuntime 介紹
Intro
前面集成 Prometheus 的文章中簡單提到過，prometheus-net.DotNetRuntime 可以獲取到一些 CLR 的數據，比如說 GC, ThreadPool, Contention, JIT 等指標，而這些指標可以很大程度上幫助我們解決很多問題，比如應用執行過程中是否經常發生 GC，GC 等待時間時間是否過長，是否有發生死鎖或競爭鎖時間過長，是否有發生線程池餓死等等一系列問題，有了這些指標我們就可以清晰的在運行時了解到這些信息。
來看一下官方介紹
A plugin for the prometheus-net package, exposing .NET core runtime metrics including:
- Garbage collection collection frequencies and timings by generation/ type, pause timings and GC CPU consumption ratio
- Heap size by generation
- Bytes allocated by small/ large object heap
- JIT compilations and JIT CPU consumption ratio
- Thread pool size, scheduling delays and reasons for growing/ shrinking
- Lock contention
- Exceptions thrown, broken down by type
These metrics are essential for understanding the peformance of any non-trivial application. Even if your application is well instrumented, you're only getting half the story- what the runtime is doing completes the picture.
支持的指標
Contention Events
只要運行時使用的 System.Threading.Monitor 鎖或 Native鎖出現爭用情況，就會引發爭用事件。
一個線程等待的鎖被另一線程占有時將發生爭用。
| Name | Description | Type |
|---|---|---|
| dotnet_contention_seconds_total | 發生鎖爭用的耗時(秒)總計 | Counter |
| dotnet_contention_total | 鎖爭用獲得鎖的數量總計 | Counter |
Thread Pool Events
Worker thread 線程池和 IO thread 線程池信息
| Name | Description | Type |
|---|---|---|
| dotnet_threadpool_num_threads | 線程池中活躍的線程數量 | Gauge |
| dotnet_threadpool_io_num_threads | IO 線程池中活躍線程數量(WindowsOnly) | Gauge |
| dotnet_threadpool_adjustments_total | 線程池中線程調整總計 | Counter |
Garbage Collection Events
Captures information pertaining to garbage collection, to help in diagnostics and debugging.
| Name | Description | Type |
|---|---|---|
| dotnet_gc_collection_seconds | 執行 GC 回收過程耗費的時間（秒） | Histogram |
| dotnet_gc_pause_seconds | GC 回收造成的 Pause 耗費的時間（秒） | Histogram |
| dotnet_gc_collection_reasons_total | 觸發 GC 垃圾回收的原因統計 | Counter |
| dotnet_gc_cpu_ratio | 運行垃圾收集所花費的進程CPU時間的百分比 | Gauge |
| dotnet_gc_pause_ratio | 進程暫停進行垃圾收集所花費的時間百分比 | Gauge |
| dotnet_gc_heap_size_bytes | 當前各個 GC 堆的大小 (發生垃圾回收之后才會更新) | Gauge |
| dotnet_gc_allocated_bytes_total | 大小對象堆上已分配的字節總數（每100 KB分配更新） | Counter |
| dotnet_gc_pinned_objects | pinned 對象的數量 | Gauge |
| dotnet_gc_finalization_queue_length | 等待 finalize 的對象數 | Gauge |
JIT Events
| Name | Description | Type |
|---|---|---|
| dotnet_jit_method_total | JIT編譯器編譯的方法總數 | Counter |
| dotnet_jit_method_seconds_total | JIT編譯器中花費的總時間（秒） | Counter |
| dotnet_jit_cpu_ratio | JIT 花費的 CPU 時間 | Gauge |
集成方式
上面的列出來的指標是我覺得比較重要的指標，還有一些 ThreadPool Scheduling 的指標和 CLR Exception 的指標我覺得意義不是特別大，有需要的可以去源碼里看一看
集成的方式有兩種，一種是作者提供了一個默認的 Collector 會去收集所有支持的 CLR 指標信息，另外一種則是可以自己自定義的要收集的 CLR 指標類型，來看示例：
使用默認的 Collector 收集 CLR 指標
DotNetRuntimeStatsBuilder.Default().StartCollecting();
使用自定義的 Collector 收集 CLR 指標
DotNetRuntimeStatsBuilder.Customize()
.WithContentionStats() // Contention event
.WithGcStats() // GC 指標
.WithThreadPoolStats() // ThreadPool 指標
// .WithCustomCollector(null) // 你可以自己實現一個自定義的 Collector
.StartCollecting();
上面提到過默認的 Collector 會收集支持的所有的 CLR 指標，且看源碼怎么做的
構建了一個 Builder 通過建造者模式來構建復雜配置的收集器，類似於 .net core 里的 HostBuilder/LoggingBuilder ...，像極了 Host.CreateDefaultBuilder，做了一些變形
實現原理
那它是如何工作的呢，如何實現捕獲 CLR 的指標的呢，下面我們就來解密一下，
在項目 README 里已經有了簡單的介紹，是基於 CLR 的 ETW Events 來實現的，具體的 CLR 支持的 ETW Events 可以參考文檔：https://docs.microsoft.com/en-us/dotnet/framework/performance/clr-etw-events
而 ETW Events 是通過 EventSource 的方式使得我們可以在進程外獲取到進程的一些運行信息，這也是我們可以通過 PerfMonitor/PerfView 等方式進程外獲取進程 CLR 信息的重要實現方式，同樣的微軟的新的診斷工具 dotnet diagnostic tools 的實現方式 EventPipe 也是基於 EventSOurce 的
而 EventSource 的事件不僅僅可以通過進程外的這些工具來消費，我們也可以在應用程序中實現 EventListener 來實現進程內的 EventSource 事件消費，而這就是 prometheus-net.DotNetRuntime 這個庫的實現本質方法
具體的事件處理是在對應的 Collector 中：
Metrics Samples
為了比較直觀的看到這些指標可以帶來的效果，分享一下我的應用中用到的一些 dashboard 截圖
Lock Contention
GC
從上面的圖可以清晰的看到這個時間點發生了一次垃圾回收，此時 GC Heap 的大小和 GC 垃圾回收的CPU 占用率和耗時都可以大概看的出來，對於我們運行時診斷應用程序問題會很有幫助
Thread
Thread 的信息還可以拿到一些 threadpool 線程調度的數量以及延遲，這里沒有展示出來，
目前我主要關注的是線程池中線程的數量和線程池線程調整的原因，線程池線程調整的原因中有一個是 starvation，這個指標尤其需要關注一下，應避免出現 threadpool starvation 的情況，出現這個的原因通常是因為有一些不當的用法，如： Task.Wait、Task.Result、await Task.Run() 來把一個同步方法變成異步等不好的用法導致的
DiagnosticSource
除了 EventSource 之外，還有一個 DiagnosticSource 可以幫助我們診斷應用程序的性能問題，目前微軟也是推薦類庫中使用 DiagnosticSource 的方式來讓應用診斷類庫中的一些性能問題，這也是目前大多數 APM 實現的機制，Skywalking、ElasticAPM、OpenTelemetry 等都使用了 DiagnosticSource 的方式來實現應用程序的性能診斷
如果是進程外應用程序的性能診斷推薦首選 EventSource，如果是進程內推薦首選 DiagnosticSource
通常我們都應該使用 DiagnosticSource，即使想進程外捕獲，也是可以做到的
關於這二者的使用，可以看一下這個 Comment https://github.com/dotnet/aspnetcore/issues/2312#issuecomment-359514074
More
除了上面列出來的那些指標還有一些指標，比如 exception，threadpool scheduling，還有當前 dotnet 的環境（系統版本，GC 類型，Runtime 版本，程序 TargetFramework，CPU 數量等），有興趣的可以用一下試一下
exception 指標使用下來感覺幫助不大，有一些即使是已經處理的或者忽略的 Exception 也會被統計，這些 Exception 大多並不會影響應用程序的運行，如果參考這個的話可能會帶來很多的困擾，所以我覺得還是需要應用程序來統計 exception 指標更為合適一些
prometheus-net.DotNetRuntime 作為 prometheus-net 的一個插件，依賴於 prometheus-net 去寫 metrics 信息，也就是說 metrics 的信息可以通過 prometheus-net 來獲取
集成 asp.net core 的時候和之前集成 prometheus-net 是一樣的，metrics path 是同一個，可以參考我這個項目: https://github.com/OpenReservation/ReservationServer/tree/dev/OpenReservation
注意：作者推薦 .netcore3.0 以上使用，.netcore 2.x 會有一些 BUG，可以在 Issue 里看到