V4

[djluck]

Summary

A large refactor that aims to make this library far more stable and performant by default. Event counters are now the default source of metrics while more detailed events can be enabled manually when required (see CaptureLevel).

Changes

Breaking changes

• Dropped support for prometheus-net v2.
• Dropped support for netcoreapp2.2
• WithThreadPoolSchedulingStats has been removed- it was both a performance hog and incorrect (the IDs of the start/stop events were not stable). May consider adding this in a later release as .NET 5.0 should have fixed the stable IDs issue.
• DotNetRuntimeStatsBuilder.Default() now only uses event counters to generate metrics. JIT metrics will not be collected (there are no JIT-related event counters in .NET core 3.1). Plan to add support for .NET 5.0 in a later release. You can restore more detailed metrics by using DotNetRuntimeStatsBuilder.Customize() and passing a custom CaptureLevel.
• Renamed dotnet_gc_collection_reasons_total -> dotnet_gc_collection_count_total

Additions/ enhancements

• Added new threadpool metrics: dotnet_threadpool_throughput_total, dotnet_threadpool_queue_length and dotnet_threadpool_timer_count
• Added dotnet_gc_memory_total_available_bytes to track the total amount of memory .NET can allocate to (this takes into account docker memory limits)
• Added ability to configure the source of majority of collectors- can either be driven solely by event counters (CaptureLevel.Counters) or event listeners for more detailed metrics.
• Added support for recycling EventListeners periodically (net5.0 only as netcoreapp3.1 is impacted by Deadlock on EventListeners being enabled/ re-enabled  dotnet/runtime#49804).
• Improved the collection of debugging metrics available
• Added documentation around metrics exposed
• Added an example docker-compose stack that can be used for testing and experimentation

Fixes

• Dashboard incomplete #9
• Capture thread pool throughput #10
• Thread pool scheduling metrics are incomplete #20
• Dashboard time interval is hardcoded to Aug, 2019, which is confusing #33
• Record ThreadPool.PendingWorkItemCount Property #35
• Document metrics exposed #39

[WeihanLi]

Any plan for adding netcoreapp3.1 and net5.0 target?

[djluck]

@WeihanLi I can add those as targets. Out of interest, what benefits do you see from targeting net5.0 vs netstandard2.1?

[WeihanLi]

I had seen the roadmap on event counters, some counters may available only for .net5.0 so maybe it's better to have a target for net5.0, just a mind, not for sure.

Some well-known counters I'd seen before, hope it would help on the feature for event counters.
https://github.com/dotnet/diagnostics/blob/master/src/Tools/dotnet-counters/KnownData.cs

@djluck I'd another question that if .netstandard2.1 is enough, why are we adding the target for netcoreapp3.0, shall we just keep the target for netstandard2.1?

[djluck]

@WeihanLi I think the set of available counters is determined by the runtime version that the hosting application is using, not the SDK although I'll be testing this to be sure.

[WeihanLi]

Yeah, thanks for your reply. @djluck

[pcwiese]

I can see you are actively working on incorporating EventCounters into the mix (among a bunch of other stuff). That's really great! Do you have a sense of the timeline for the 4.0 release? I was just about to fork this and add some stuff for EventCounters, but I really don't want to duplicate work if you are already moving on it.

[djluck]

Hey @pcwiese, progress has been really solid recently, so I'm hoping to have a v4.0 beta available within the next week.