Enable OpenTelemetry by default and deprecate EnableOpenTelemetry

[Copilot]

OpenTelemetry guidelines specify telemetry should be emitted by default. Currently requires explicit opt-in via endpointConfiguration.EnableOpenTelemetry().

Changes

Core

• EndpointConfiguration: Added OpenTelemetryFeature to default-enabled features list
• HostingComponent.Settings: EnableOpenTelemetry property removed
• obsoletes-v10.cs: Deprecated EnableOpenTelemetry() as compile error (v10), removed in v11

Tests

• Deleted OpenTelemetryEnabledEndpoint - redundant since now default
• Replaced all test usages with DefaultServer

Usage

Before:

var config = new EndpointConfiguration("MyEndpoint");
config.EnableOpenTelemetry(); // Required to get telemetry

After:

var config = new EndpointConfiguration("MyEndpoint");
// OpenTelemetry enabled by default

Existing calls to EnableOpenTelemetry() will produce compile errors with migration guidance.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• f.feedz.io
  • Triggering command: /usr/bin/dotnet dotnet build src/NServiceBus.Core/NServiceBus.Core.csproj (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Currently it is required to opt-into telemetry by doing endpointConfiguration.EnableOpenTelemetry(); which activates the open telemetry feature. This seems to violate our guidance in https://github.com/Particular/Platform/blob/main/guidelines/open-telemetry-guidelines.md#general which states "The telemetry that we do decide to emit, should be emitted by default.". Deprecate the EnableOpenTelemetry method, enable the feature by default (probably best somewhere here https://github.com/Particular/NServiceBus/blob/master/src/NServiceBus.Core/EndpointConfiguration.cs#L63) and introduce a DisableOpenTelemetry method. Adjust tests as necessary. Favour minimal changes and follow the coding standards in the files changed

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[ramonsmits]

Wondering if we can do something like the following in the feature setup?

if (!ActivitySources.Main.HasListeners())
    return;

In the feature setup. If is safe to assume that when Endpoint.Create/Start is invoked OTel is initialized?

[danielmarbach]

@ramonsmits I looked into this briefly and concluded there might be too many ordering dragons so I went with the most straightforward approach for now. Happy to revisit if you think it is feasible.

Maybe the best way is to properly change the activity factory to follow those guidelines we have

For traces: check activitySource.HasListeners() before creating an Activity.

[danielmarbach]

@ramonsmits have a look. I think this is a viable approach that addresses your input too.

[danielmarbach]

I wonder if EnableOpenTelemetry is a misnomer from the beginning and changing it to DisableOpenTelemetry would carry forward the misnomer. Looking at the documentation

https://docs.particular.net/nservicebus/operations/opentelemetry

it becomes clear that EnableOpenTelemetry only over enabled the traces and assumed, for example metrics are enabled by configuring the corresponding metric listeners. So there was a double-opt in to traces and not open telemetry as a whole. I updated the documentation on DisableOpenTelemetry to reflect that but I think it should be renamed to DisableOpenTelemetryTraces or something similar.

I can only see this disable mechanism as being useful for a case where you have AddSource in your standard template but for some weird reason you want to disable the traces creation. But given you could simply remove the sources I'm wondering why would this even be necessary?

So the only reason I can come up with that we need this API is because

A user COULD invoke AddSource("NServiceBus.*") and NOT endpointConfiguration.EnableOpenTelemetry(); which now would result in emitting metrics/traces starting from this version.

Thoughts?

[ramonsmits]

I can only see this disable mechanism as being useful for a case where you have AddSource in your standard template but for some weird reason you want to disable the traces creation. But given you could simply remove the sources I'm wondering why would this even be necessary?

I would drop that API completely. IMHO enabling OTel should be done only via its own API and we should follow/adapt.

[danielmarbach]

I would drop that API completely. IMHO enabling OTel should be done only via its own API and we should follow/adapt.

I tend to agree, especially because this is done in a major version the behavior change outlined in

A user COULD invoke AddSource("NServiceBus.*") and NOT endpointConfiguration.EnableOpenTelemetry(); which now would result in emitting metrics/traces starting from this version.

can be added to the upgrade guide and the flag could be reintroduced later in a minor version if really needed.

[danielmarbach]

For reference @timbussmann original PR #6445

@mikeminutillo You mentioned

I'm not a fan of the double opt-in. If we're going to do that I prefer an opt-out API for optimization. It still feels weird to have to make the decision twice though.

Maybe you'd like to review this also after reading #7577 (comment)

[Copilot]

Pull request overview

This PR enables OpenTelemetry instrumentation by default in NServiceBus, aligning with OpenTelemetry guidelines that telemetry should be emitted by default rather than requiring explicit opt-in.

Key Changes:

• OpenTelemetry feature now enabled by default in endpoint configuration
• EnableOpenTelemetry() extension method deprecated as a compile-time error (v10) and removed in v11
• ActivityFactory optimized with early exit when no diagnostic listeners are present
• Test infrastructure simplified by removing OpenTelemetryEnabledEndpoint and using DefaultServer throughout

Reviewed changes

Copilot reviewed 37 out of 38 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/NServiceBus.Core/EndpointConfiguration.cs	Added OpenTelemetryFeature to the list of default-enabled features
src/NServiceBus.Core/obsoletes-v10.cs	Added deprecation for EnableOpenTelemetry() extension method
src/NServiceBus.Core/OpenTelemetry/OpenTelemetryConfigurationExtensions.cs	Deleted file - functionality moved to obsoletes
src/NServiceBus.Core/Hosting/HostingComponent.Settings.cs	Removed EnableOpenTelemetry property (no longer needed)
src/NServiceBus.Core/Hosting/HostingComponent.Configuration.cs	Always uses ActivityFactory instead of conditionally switching to NoOpActivityFactory
src/NServiceBus.Core/OpenTelemetry/Tracing/ActivityFactory.cs	Added early exit optimization when no listeners present; refactored null checks to use early return pattern
src/NServiceBus.Core/OpenTelemetry/Tracing/NoOpActivityFactory.cs	Added sealed modifier for performance
src/NServiceBus.Core.Tests/OpenTelemetry/ActivityFactoryTests.cs	Added unit tests for no-listener scenario
src/NServiceBus.AcceptanceTests/Core/OpenTelemetry/When_no_listener_available.cs	New acceptance test verifying behavior when no diagnostic listeners are present
src/NServiceBus.AcceptanceTests/Core/OpenTelemetry/OpenTelemetryEnabledEndpoint.cs	Deleted - no longer needed since OpenTelemetry is now default
Multiple test files	Replaced OpenTelemetryEnabledEndpoint with DefaultServer; removed explicit EnableOpenTelemetry() calls
src/NServiceBus.Core.Tests/ApprovalFiles/APIApprovals.ApproveNServiceBus.approved.txt	Updated to show obsolete attribute on EnableOpenTelemetry
src/NServiceBus.AcceptanceTests/ApprovalFiles/When_pipelines_are_built.Should_preserve_order.approved.txt	Shows OpenTelemetry behaviors now in default pipeline

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[danielmarbach]

@mikeminutillo I'm merging. Should you have comments I'm happy to address those later