feat: Add support to send OTEL traces via OTLP by jamescrosswell · Pull Request #4899 · getsentry/sentry-dotnet

jamescrosswell · 2026-02-09T00:54:21Z

Resolves: #4859

Investigate OTLP integration #4859

github-actions · 2026-02-09T00:54:43Z

Semver Impact of This PR

⚪ None (no version bump detected)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

Features ✨

feat: Add support to send OTEL traces via OTLP by jamescrosswell in #4899

Dependencies ⬆️

chore(deps): update Native SDK to v0.12.7 by github-actions in #4920

Other

test(android): Use volatile to produce SIGSEGV in native crash test by jpnurmi in #4919

_{🤖 This preview updates automatically when you update the PR.}

github-actions · 2026-02-09T00:54:50Z

	Fails
🚫	Please consider adding a changelog entry for the next release.

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

### Features

- Add support to send OTEL traces via OTLP ([#4899](https://github.com/getsentry/sentry-dotnet/pull/4899))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against 8fbbf89

jamescrosswell · 2026-02-09T00:58:33Z

samples/Sentry.Samples.OpenTelemetry.AspNetCore/Program.cs

-            // Finally we configure OpenTelemetry to send traces to Sentry
-            .AddSentry()
+            // Finally, we configure OpenTelemetry to send traces to Sentry
+            .AddSentry(dsn)


This is unfortunately a bit more complex for SDK users to initialise because the TracerProviderBuilder.AddOtlpExporter method has no override with an IServiceProvider parameter (so there's no way to read the DSN from the sentry options that get added to the service registry later on).

jamescrosswell · 2026-02-09T01:01:22Z

samples/Sentry.Samples.OpenTelemetry.AspNetCore/Sentry.Samples.OpenTelemetry.AspNetCore.csproj

    <PackageReference Include="OpenTelemetry.Instrumentation.AspNetCore" Version="1.8.1" />
    <PackageReference Include="OpenTelemetry.Instrumentation.Http" Version="1.8.1" />
    <PackageReference Include="OpenTelemetry.Instrumentation.Runtime" Version="1.8.0" />
+    <PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.8.1" />


Without adding an explicit reference to this package, we get an error because the other packages try to load types from a different assembly version. It's the workaround for this problem basically.

jamescrosswell · 2026-02-09T01:02:54Z

src/Sentry.OpenTelemetry/TracerProviderBuilderExtensions.cs

+        ///     </para>
+        /// </param>
+        /// <returns>The supplied <see cref="TracerProviderBuilder"/> for chaining.</returns>
+        public TracerProviderBuilder AddSentry(TextMapPropagator? defaultTextMapPropagator = null)


We could mark this overload obsolete if we wanted to encourage SDK users to move to the OTLP version of the integration... then remove it in a future major release.

src/Sentry.OpenTelemetry/SentryOptionsExtensions.cs

codecov · 2026-02-09T21:28:30Z

Codecov Report

❌ Patch coverage is 25.71429% with 52 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.69%. Comparing base (48b744f) to head (907850b).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
...y.OpenTelemetry/TracerProviderBuilderExtensions.cs	5.26%	18 Missing ⚠️
...rc/Sentry.OpenTelemetry/SentryOptionsExtensions.cs	0.00%	13 Missing ⚠️
src/Sentry.OpenTelemetry/OtelPropagationContext.cs	0.00%	8 Missing ⚠️
...i.CommunityToolkit.Mvvm/SentryOptionsExtensions.cs	0.00%	3 Missing ⚠️
src/Sentry/Internal/Hub.cs	0.00%	2 Missing and 1 partial ⚠️
src/Sentry/SentryGraphQLHttpMessageHandler.cs	0.00%	2 Missing and 1 partial ⚠️
src/Sentry/SentryHttpMessageHandler.cs	0.00%	2 Missing and 1 partial ⚠️
src/Sentry/Dsn.cs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4899      +/-   ##
==========================================
- Coverage   73.87%   73.69%   -0.18%     
==========================================
  Files         494      495       +1     
  Lines       17868    17919      +51     
  Branches     3509     3523      +14     
==========================================
+ Hits        13200    13206       +6     
- Misses       3808     3851      +43     
- Partials      860      862       +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jamescrosswell · 2026-02-09T21:34:59Z

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Odd that we're still seeing this after having moved to conventional commits.

It doesn't look like the danger workflow is aware of our release.yml file or accounts for this in it's logic.

@Flash0ver any ideas what we might be doing wrong?

src/Sentry.OpenTelemetry/TracerProviderBuilderExtensions.cs

Flash0ver · 2026-02-09T22:18:56Z

@Flash0ver any ideas what we might be doing wrong?

I'm not sure how to remove the Danger Changelog Missing automation off the top of my head ... I'll look into it tomorrow.

jamescrosswell · 2026-02-10T01:00:40Z

src/Sentry/Internal/Hub.cs

            return NoOpTransaction.Instance;
        }

+        if (_options.Instrumenter == Instrumenter.OpenTelemetry)


This would be a pretty major change...

It would break the Sentry.Extensions.AI integration for a start (we'd need to provide a Sentry.Extensions.AI.OpenTelemetry integration instead).

It may break lots of user code that assumes we support mixed instrumentation in a single process (which we did up until now)

Potentially we leave this commented out as a todo for v7.0.0 and we just strongly advise SDK users not to use mixed instrumentation until then as we can't guarantee it will work as expected.

@Flash0ver @dingsdax thoughts?

src/Sentry.OpenTelemetry/SentryOptionsExtensions.cs

Flash0ver · 2026-02-11T07:56:45Z

src/Sentry.OpenTelemetry/Sentry.OpenTelemetry.csproj

  <ItemGroup>
    <!-- Version 1.6.0 is the minimum version that does not have trim warnings   -->
-    <PackageReference Include="OpenTelemetry" Version="1.6.0" />
+    <PackageReference Include="OpenTelemetry.Exporter.OpenTelemetryProtocol" Version="1.6.0" />


next major: consider bumping to >= 1.11.0, as the dependency graph looks cleaner

jamescrosswell · 2026-02-12T04:12:06Z

src/Sentry/DynamicSamplingContext.cs

+    /// </summary>
+    /// <exception cref="ArgumentOutOfRangeException">Can be thrown when using OpenTelemetry instrumentation and
+    /// System.Diagnostics.Activity.Current is null. This method should not be used when instrumenting with OTEL.
+    /// </exception>


This is problematic... the alternative would be to drop the guard here:

sentry-dotnet/src/Sentry/DynamicSamplingContext.cs

Lines 34 to 38 in 6f8312d

// Validate and set required values

if (traceId == SentryId.Empty)

{

throw new ArgumentOutOfRangeException(nameof(traceId), "cannot be empty");

}

...or to replace it with a log rather than throwing an exception. However then I think we risk sending invalid envelopes to Sentry and losing events if Sentry drops these.

I think this is the correct approach. The only code that we have which was using this was in the SentryMessageHandler implementations.

There is one small additional risk because it's also used by the GetBaggage method, which is part of the public SDK. I added some code to log a warning if that method is called when OTEL instrumentation is being used:

sentry-dotnet/src/Sentry/Internal/Hub.cs

Lines 313 to 328 in 6f8312d

public BaggageHeader GetBaggage()

{

if (_options.Instrumenter is Instrumenter.OpenTelemetry)

{

_options.LogWarning("GetBaggage should not be called when using OpenTelemetry - it may throw an exception");

}

var span = GetSpan();

if (span?.GetTransaction().GetDynamicSamplingContext() is { IsEmpty: false } dsc)

{

return dsc.ToBaggageHeader();

}

var propagationContext = CurrentScope.PropagationContext;

return propagationContext.GetOrCreateDynamicSamplingContext(_options, _replaySession).ToBaggageHeader();

}

And I added some info about the possible exception to the public XML docs for that method:

sentry-dotnet/src/Sentry/IHub.cs

Lines 73 to 75 in 6f8312d

/// <exception cref="ArgumentOutOfRangeException">Can be thrown when using OpenTelemetry instrumentation and

/// System.Diagnostics.Activity.Current is null. This method should not be used when instrumenting with OTEL.

/// </exception>

It's not great, but I can't think of any better ways to handle it. @Flash0ver thoughts?

Hmmm .... not sure if ArgumentOutOfRangeException is the correct exception here, as it's usually used when numeric values are greater than or less than expected ... maybe just ArgumentException ... but I'm not really answering the question, aren't I?!

Another thought that I'm having is that we're quite inconsistent with Argument validation:
At some locations we throw, e.g. ArgumentNullException, at other places we don't throw but only log via the DiagnosticLogger if enabled. But again, no solution to the problem.

Perhaps we could solve this issue with an Analyzer.
Throw at run-time, and warn at build-time for invocations of this method when Sentry.OpenTelemetry is referenced. This may cause some false positives in cases where Sentry.OpenTelemetry is referenced, but actually not initialized and the Instrumenter is not Instrumenter.OpenTelemetry at runtime. But it would be a bit of a "best effort" solution. At least there shouldn't be false negatives ... unless I am missing something.

(thought: it seems that every time I'm out of ideas, I suggest some Compiler Extension to fix it 😉)

Follow-up thought:
I suppose the best solution would be to make this method actually not invocable when the is Instrumenter.OpenTelemetry. Well, if the option is not set at runtime, we can't just remove this method at build time.

Just for some brain-storming: Maybe we could re-direct the invocation - via an Interceptor - to another method if Sentry.OpenTelemetry is referenced ... but this solution has the same issue as the Analyzer from above: at build-time, we only know whether Sentry.OpenTelemetry is referenced, not if OpenTelemetry is actually initialized .. well, we could scan for the respective AddSentry/UseSentry invocation, but what if there are more than one Hubs ... we can't really draw the connection there unambiguously.

we're quite inconsistent with Argument validation:
At some locations we throw, e.g. ArgumentNullException, at other places we don't throw but only log via the DiagnosticLogger if enabled. But again, no solution to the problem.

I don't really want to throw an exception here... it's not by design. However:

I can't change the signature for the public API (it has a public GetBaggage method that returns a non-nullable type)

The only other option would be to suppress the error and return an empty SentryId representing the TraceId... but then we risk Sentry dropping events.

Maybe, if the GetBaggage() method is called when OTEL tracing is enabled, we log a warning and simply return an emply baggage header? That way we avoid the possibility of our code erroring out (we never call this method if OTEL tracing is enabled... we can but an assert in there to ensure this) but we do make it really clear the method shouldn't be used with OTEL tracing?

Hmmm .... not sure if ArgumentOutOfRangeException is the correct exception here, as it's usually used when numeric values are greater than or less than expected ... maybe just ArgumentException ... but I'm not really answering the question, aren't I?!

We could change that... I think the traceId is essentially a GUID and you get an out of range if this is empty (i.e. all zeros)... if you squint, a guid is kind of a number but you have to squint 😜

Added support to send OTEL traces via OTLP

2122abb

Resolves: #4859 - #4859

jamescrosswell commented Feb 9, 2026

View reviewed changes

jamescrosswell mentioned this pull request Feb 9, 2026

Investigate OTLP integration #4859

Open

Flash0ver reviewed Feb 9, 2026

View reviewed changes

src/Sentry.OpenTelemetry/SentryOptionsExtensions.cs Outdated Show resolved Hide resolved

Added OTEL propagation context to link OTEL spans to events etc.

a2fb0e4

Flash0ver reviewed Feb 9, 2026

View reviewed changes

src/Sentry.OpenTelemetry/TracerProviderBuilderExtensions.cs Outdated Show resolved Hide resolved

Disable Sentry tracing instrumentation if OTEL is enabled

442fc7d

jamescrosswell commented Feb 10, 2026

View reviewed changes

Revert to classic extension methods

08d8711

Flash0ver mentioned this pull request Feb 10, 2026

ci(danger): disable CHANGELOG check #4910

Draft

jamescrosswell commented Feb 11, 2026

View reviewed changes

src/Sentry.OpenTelemetry/SentryOptionsExtensions.cs Outdated Show resolved Hide resolved

Flash0ver reviewed Feb 11, 2026

View reviewed changes

jamescrosswell added 2 commits February 12, 2026 13:35

Added option to disable sentry tracing

907850b

Added some new tests... found some new issues

6f8312d

jamescrosswell commented Feb 12, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into oltp-integration

8fbbf89

	// Validate and set required values
	if (traceId == SentryId.Empty)
	{
	throw new ArgumentOutOfRangeException(nameof(traceId), "cannot be empty");
	}

	public BaggageHeader GetBaggage()
	{
	if (_options.Instrumenter is Instrumenter.OpenTelemetry)
	{
	_options.LogWarning("GetBaggage should not be called when using OpenTelemetry - it may throw an exception");
	}

	var span = GetSpan();
	if (span?.GetTransaction().GetDynamicSamplingContext() is { IsEmpty: false } dsc)
	{
	return dsc.ToBaggageHeader();
	}

	var propagationContext = CurrentScope.PropagationContext;
	return propagationContext.GetOrCreateDynamicSamplingContext(_options, _replaySession).ToBaggageHeader();
	}

	/// <exception cref="ArgumentOutOfRangeException">Can be thrown when using OpenTelemetry instrumentation and
	/// System.Diagnostics.Activity.Current is null. This method should not be used when instrumenting with OTEL.
	/// </exception>

Uh oh!

Conversation

jamescrosswell commented Feb 9, 2026

Uh oh!

github-actions bot commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Semver Impact of This PR

Features ✨

Dependencies ⬆️

Other

Uh oh!

github-actions bot commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Instructions and example for changelog

Uh oh!

jamescrosswell Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

codecov bot commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jamescrosswell commented Feb 9, 2026

Uh oh!

Uh oh!

Flash0ver commented Feb 9, 2026

Uh oh!

jamescrosswell Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Flash0ver Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Flash0ver Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Feb 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions bot commented Feb 9, 2026 •

edited

Loading

github-actions bot commented Feb 9, 2026 •

edited

Loading

jamescrosswell Feb 9, 2026 •

edited

Loading

codecov bot commented Feb 9, 2026 •

edited

Loading

Flash0ver Feb 13, 2026 •

edited

Loading

jamescrosswell Feb 15, 2026 •

edited

Loading