Skip to content

Sentry Metrics for .NET #4741

Closed
Closed

Description

@dingsdax

https://develop.sentry.dev/sdk/telemetry/metrics/

Add support for Sentry Metrics to the .NET SDK!

This will enable users to record counters, gauges, and distributions.

  1. Define the Metrics Protocol and trace_metric envelope type in the SDK.
  2. Add the Public API (SDK options and methods) as per the docs.
  3. Make sure the the SDK follow the documented behavior.
  4. Attach default attributes and optional user attributes to the SDK as per docs.
  5. 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.

Activity

  1. linear commented on Nov 16, 2025

    @linear
  2. intrepid-developer commented on Nov 25, 2025

    @intrepid-developer

    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:

    Image
  3. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Nov 25, 2025
  4. Flash0ver commented on Nov 25, 2025

    @Flash0ver
    Contributor

    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.

  5. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Nov 25, 2025
  6. Flash0ver commented on Nov 26, 2025

    @Flash0ver
    Contributor

    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.

  7. intrepid-developer commented on Nov 26, 2025

    @intrepid-developer

    @Flash0ver thanks for the update 👍 Looking forward to getting this early next year 😄

  8. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Nov 26, 2025
  9. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Nov 27, 2025
  10. FraserKillip commented on Feb 12, 2026

    @FraserKillip

    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

  11. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Feb 12, 2026
  12. Flash0ver commented on Feb 12, 2026

    @Flash0ver
    Contributor

    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:

    • which built-in metrics of the platform to collect automatically
      • .NET, ASP.NET Core, .NET MAUI, Extensions metrics, ...
      • Well-known EventCounters
      • additional Instruments like MySqlConnector Metrics
      • all of them?
    • 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.

    i.e. Collect metrics

    e.g.

    internal sealed class MetricsExporterHostedService : BackgroundService
    {
        private readonly MeterListener _meterListener = new();
        private readonly PeriodicTimer _timer = new(TimeSpan.FromSeconds(2));
    
        protected override async Task ExecuteAsync(CancellationToken stoppingToken)
        {
            _meterListener.InstrumentPublished = static (instrument, listener) =>
            {
                if (instrument.Meter.Name is "Microsoft.AspNetCore.Hosting")
                {
                    if (instrument.Name is "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();
            }
    
            static void OnMeasurementRecorded(Instrument instrument, double measurement, ReadOnlySpan<KeyValuePair<string, object>> tags, object state)
            {
                if (instrument.Name is "http.server.request.duration")
                {
                    SentrySdk.Experimental.Metrics.EmitDistribution(instrument.Name, measurement, MeasurementUnit.Duration.Second, tags);
                }
            }
        }
    
        public override void Dispose()
        {
            _timer.Dispose();
            _meterListener.Dispose();
            base.Dispose();
        }
    }

    Perhaps we should add this, or a similar, example to the documentation.

  13. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Feb 12, 2026
  14. Flash0ver commented on Feb 12, 2026

    @Flash0ver
    Contributor

    For follow-up discussions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

.NETPull requests that update .net codeFeatureNew feature or requestMetrics

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions