You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow requirements for rate limiting, buffering, batching & flushing and build in measures to prevent excessive memory usage.
For general feedback & questions about Sentry Metrics use this GH discussion; for .NET SDK specific feedback & questions use the comment functionality on this GH issue.
Reacted by Mauro van der Gun, Eric Sampson and K Nevostruev
Metrics are currently in beta, and we are continuously widening the support for our SDKs.
And our .NET SDK is indeed on the Roadmap: we plan to ship Metrics as an Experimental API soon after we publish v6.0.0 as stable ... depending a bit on the upcoming holiday season.
We're starting with an Experimental API since the feature's still in Beta, and also for us to get feedback on the API shape. In particular on the "Attributes"-related parts, as "Attributes" will be quite pervasive in future versions of the SDK.
We also learned from supporting Logs ... so, during the Experimental phase, we will add features more incrementally ... during which we are very much looking forward to your feedback.
We don't have concrete plans for integrations just yet, like .NET Counters, such as System.Runtime, System.Net.*, Microsoft.AspNetCore.*, etc. ... as well as allowing to connect custom Metrics ... but I'll get back to you on that after we released basic support.
Reacted by Chris Vanderplank, Dominic Schira and davidames
Sorry @intrepid-developer ... I might have jumped the gun here a bit, considering all the other things we have on our plate ... in particular #4427, as well as rounding things off on Structured Logging ... we want to finish the features we have in store before tacking new ones.
We are hoping to have Metrics complete in .NET in Q1/Q2 2026.
We'll reach out when we got some Experimental parts of it ready for you to try out and give feedback on.
More generally than the dotnet counters it would be great if Sentry could support OTEL metrics out of the box using the existing meters implementation.
I imagine this could work a similar way to how logs support ILogger and Serilog out of the box
Currently, we are - internally - looking into a per-SDK approach for auto-collected Metrics.
Our current focus is on polishing the product during it's Open Beta, and get feedback about our API choices for the Sentry .NET SDK, which we are planning to move from Experimental to Stable by March.
We will follow-up with a perhaps not "one-size-fits-all", but "out-of-the-box-fits-most-projects-in-strong-correlation-with-other-data-like-traces-and-logs-in-Sentry" solution.
But the devil is most certainly in the details:
which built-in metrics of the platform to collect automatically
.NET, ASP.NET Core, .NET MAUI, Extensions metrics, ...
in which frequency do we collect ObservableInstruments?
make configurable with a sensible default
We do very much welcome and appreciate your feedback on which "default metrics" would be most valuable for your scenario(s).
As a matter of fact, we've designed the current shape of the SentrySdk.Experimental.Metrics.Emit* APIs to be (mostly) compatible with the .NET 6.0+ System.Diagnostics.Metrics APIs. In particular, with the goal to make an integration with the MeterListener as straightforward as possible.
internalsealedclassMetricsExporterHostedService:BackgroundService{privatereadonlyMeterListener_meterListener=new();privatereadonlyPeriodicTimer_timer=new(TimeSpan.FromSeconds(2));protectedoverrideasyncTaskExecuteAsync(CancellationTokenstoppingToken){_meterListener.InstrumentPublished=static(instrument,listener)=>{if(instrument.Meter.Nameis"Microsoft.AspNetCore.Hosting"){if(instrument.Nameis"http.server.request.duration"){listener.EnableMeasurementEvents(instrument);}}};_meterListener.SetMeasurementEventCallback<double>(OnMeasurementRecorded);_meterListener.Start();while(await_timer.WaitForNextTickAsync(stoppingToken)){// required for "ObservableInstrument<T>", which are most Instruments of the "System.Runtime" Meter_meterListener.RecordObservableInstruments();}staticvoidOnMeasurementRecorded(Instrumentinstrument,doublemeasurement,ReadOnlySpan<KeyValuePair<string,object>>tags,objectstate){if(instrument.Nameis"http.server.request.duration"){SentrySdk.Experimental.Metrics.EmitDistribution(instrument.Name,measurement,MeasurementUnit.Duration.Second,tags);}}}publicoverridevoidDispose(){_timer.Dispose();_meterListener.Dispose();base.Dispose();}}
Perhaps we should add this, or a similar, example to the documentation.
Activity
linear commentedon Nov 16, 2025
NET-531
intrepid-developer commentedon Nov 25, 2025
Do you have a planned release for this yet? This would be really good for us 😄
And, will the .Net version include all the .Net metrics that we see in things like the Aspire Dashboard?
E.g. these:
Flash0ver commentedon Nov 25, 2025
Metrics are currently in beta, and we are continuously widening the support for our SDKs.
And our .NET SDK is indeed on the Roadmap: we plan to ship Metrics as an
ExperimentalAPI soon after we publishv6.0.0as stable ... depending a bit on the upcoming holiday season.We're starting with an
ExperimentalAPI since the feature's still in Beta, and also for us to get feedback on the API shape. In particular on the "Attributes"-related parts, as "Attributes" will be quite pervasive in future versions of the SDK.We also learned from supporting Logs ... so, during the
Experimentalphase, we will add features more incrementally ... during which we are very much looking forward to your feedback.We don't have concrete plans for integrations just yet, like .NET Counters, such as
System.Runtime,System.Net.*,Microsoft.AspNetCore.*, etc. ... as well as allowing to connect custom Metrics ... but I'll get back to you on that after we released basic support.Flash0ver commentedon Nov 26, 2025
Sorry @intrepid-developer ... I might have jumped the gun here a bit, considering all the other things we have on our plate ... in particular #4427, as well as rounding things off on Structured Logging ... we want to finish the features we have in store before tacking new ones.
We are hoping to have Metrics complete in .NET in Q1/Q2 2026.
We'll reach out when we got some
Experimentalparts of it ready for you to try out and give feedback on.intrepid-developer commentedon Nov 26, 2025
@Flash0ver thanks for the update 👍 Looking forward to getting this early next year 😄
Flash0ver commentedon Jan 19, 2026
PRs ready for review:
FraserKillip commentedon Feb 12, 2026
More generally than the dotnet counters it would be great if Sentry could support OTEL metrics out of the box using the existing meters implementation.
I imagine this could work a similar way to how logs support
ILoggerand Serilog out of the boxFlash0ver commentedon Feb 12, 2026
Indeed, @FraserKillip
Currently, we are - internally - looking into a per-SDK approach for auto-collected Metrics.
Our current focus is on polishing the product during it's Open Beta, and get feedback about our API choices for the Sentry .NET SDK, which we are planning to move from Experimental to Stable by March.
We will follow-up with a perhaps not "one-size-fits-all", but "out-of-the-box-fits-most-projects-in-strong-correlation-with-other-data-like-traces-and-logs-in-Sentry" solution.
But the devil is most certainly in the details:
ObservableInstruments?We do very much welcome and appreciate your feedback on which "default metrics" would be most valuable for your scenario(s).
As a matter of fact, we've designed the current shape of the
SentrySdk.Experimental.Metrics.Emit*APIs to be (mostly) compatible with the .NET 6.0+System.Diagnostics.MetricsAPIs. In particular, with the goal to make an integration with theMeterListeneras straightforward as possible.i.e. Collect metrics
e.g.
Perhaps we should add this, or a similar, example to the documentation.
Flash0ver commentedon Feb 12, 2026
For follow-up discussions