Understanding the Distributed Tracing Decision
Modern .NET applications rarely run in isolation. Between microservices, message queues, caching layers, and external API integrations, a single user request can traverse dozens of moving parts. When something goes wrong, developers need visibility into the entire journey—not just the service that returned the error.
Want implementation-ready .NET source code you can adapt fast? Join Coding Droplets on Patreon. 👉 https://www.patreon.com/CodingDroplets
Distributed tracing provides that visibility by attaching a unique identifier to requests as they flow through your system. The challenge facing enterprise .NET teams today is choosing between two approaches: Microsoft's built-in Activity and DiagnosticSource APIs, or the industry-standard OpenTelemetry framework.
When Built-in Tracing Falls Short
The built-in tracing in .NET has served teams well for years. Activity tracks operation start and end times, while DiagnosticSource allows libraries to emit events that downstream consumers can capture. For monoliths or simple service architectures, this often suffices.
However, enterprise requirements tend to evolve in ways that expose built-in limitations:
Vendor Lock-in Concerns: Built-in tracing integrates naturally with Azure Application Insights but requires custom work for other backends. Teams adopting multi-cloud strategies or evaluating cost-effective alternatives find themselves rewriting instrumentation.
Standardization Pressure: OpenTelemetry has emerged as the industry standard, backed by cloud vendors and observability platforms alike. New team members arrive with OpenTelemetry experience, and tooling vendors prioritize its support.
Context Propagation Complexity: Propagating trace context across service boundaries with built-in APIs requires manual effort. Each HTTP client, message bus, and queue consumer needs explicit configuration to pass trace IDs downstream.
What OpenTelemetry Brings to the Table
OpenTelemetry provides a vendor-neutral instrumentation framework that addresses these gaps. Rather than coupling your code to a specific backend, you instrument once and can export to any supported backend—Datadog, New Relic, Grafana Tempo, Jaeger, or others.
The framework includes automatic instrumentation for many popular libraries, reducing the boilerplate code your team must maintain. For .NET specifically, the OpenTelemetry SDK provides ActivitySource integration that works alongside existing DiagnosticSource consumers.
Beyond vendor independence, OpenTelemetry offers semantic conventions—a standardized naming approach for spans, attributes, and metrics. This consistency matters when teams adopt multiple libraries or when you need to correlate traces with logs and metrics across your observability stack.
The Migration Reality
Moving from built-in tracing to OpenTelemetry isn't a simple flip-of-the-switch decision. Your existing instrumentation represents accumulated knowledge about your system's behavior. Discarding that context means losing valuable historical data during the transition window.
Several migration approaches exist, each with tradeoffs. You can run OpenTelemetry alongside built-in tracing during a transition period, though this increases overhead. Alternatively, you can instrument net-new services with OpenTelemetry while maintaining built-in tracing in legacy systems until rewrite cycles justify full migration.
The runtime overhead difference between approaches has narrowed significantly. Early OpenTelemetry implementations carried noticeable performance costs, but recent releases have optimized the hot path. That said, always validate in your specific environment before production deployment.
Team Considerations
Technical merit alone shouldn't drive this decision. Your team's composition and workflow matter significantly.
If your team already includes OpenTelemetry expertise, adopting the standard reduces onboarding friction for new hires. Conversely, teams with deep built-in tracing knowledge might find migration an unnecessary distraction from feature work.
Consider your tooling ecosystem. If Azure Application Insights meets your observability needs and budget, built-in tracing might require less operational complexity. If you need flexibility to evaluate alternatives or operate in multi-cloud environments, OpenTelemetry's portability becomes valuable.
Making the Call
Neither option is universally superior. The right choice depends on your context:
Choose built-in tracing if you are fully invested in Azure, have minimal cross-service tracing needs, and face no pressure to standardize on OpenTelemetry. The integration is seamless, documentation is abundant, and you avoid migration effort.
Choose OpenTelemetry if you need vendor independence, operate across multiple cloud providers, anticipate needing multiple observability backends, or face increasing instrumentation complexity that benefits from standardized approaches.
For many enterprise teams, the deciding factor isn't technical—it's organizational. If your platform team has already adopted OpenTelemetry for other languages or if your observability vendor is investing primarily in OpenTelemetry support, aligning your .NET strategy with that direction simplifies long-term maintenance.
FAQ
Does OpenTelemetry replace DiagnosticSource completely?
Not necessarily. OpenTelemetry's .NET SDK uses ActivitySource under the hood, which integrates with existing DiagnosticSource consumers. You can run both simultaneously during migration, though this adds complexity. Most teams eventually migrate fully to OpenTelemetry once they've validated the transition.
Modern OpenTelemetry implementations have minimal overhead—typically under 3% for typical workloads. However, the exact impact depends on your sampling configuration, the number of attributes you're adding to spans, and your export frequency. Always benchmark in your environment.
Can I use OpenTelemetry with Azure Application Insights?
Yes. OpenTelemetry offers an Azure Monitor exporter that sends telemetry to Application Insights. This lets you benefit from OpenTelemetry's instrumentation standardization while maintaining Azure integration.
Do I need to rewrite all my existing instrumentation?
Not immediately. Many teams run both systems concurrently, instrumenting new code with OpenTelemetry while maintaining built-in tracing in existing services. Over time, as services undergo normal development cycles, you can migrate them incrementally.
How does OpenTelemetry handle sampling?
OpenTelemetry provides several sampling strategies including deterministic head sampling, tail-based sampling, and custom samplers. Tail-based sampling is particularly valuable for enterprise workloads because it allows you to retain traces for error cases while sampling away successful requests to control costs.
