Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Capture thread pool throughput #10

Closed
djluck opened this issue Jul 25, 2019 · 0 comments
Closed

Capture thread pool throughput #10

djluck opened this issue Jul 25, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@djluck
Copy link
Owner

djluck commented Jul 25, 2019

No description provided.

@djluck djluck added the enhancement New feature or request label Jul 25, 2019
djluck added a commit that referenced this issue Mar 28, 2021
@djluck
prometheus-net.DotNetRuntime v4.0.0
e0ef923 
## 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 `EventListener`s periodically (`net5.0` only as `netcoreapp3.1` is impacted by 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
- #9
- #10
- #20
- #33
- #35
- #39
@djluck djluck mentioned this issue Mar 28, 2021
Merged
djluck added a commit that referenced this issue Mar 28, 2021
@djluck
V4 (#43)
aa9fb94 
* prometheus-net.DotNetRuntime v4.0.0

## 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 `EventListener`s periodically (`net5.0` only as `netcoreapp3.1` is impacted by 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
- #9
- #10
- #20
- #33
- #35
- #39

* Adding dedicated `netcoreapp3.1` and `net5.0` test jobs

* Fixing test job names

* Specifying framework to run tests for

* Hopefully this get's things working..

* Excluding mysteriously failing test

* Fixing filter flag
@djluck djluck closed this as completed Mar 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@djluck