The Easiest Way to Do OpenTelemetry in .NET: OTLP + Collector
Decouple your observability configuration from your application code with OTLP and collectors
19 minutes to readWe know OpenTelemetry deeply at Petabridge. We’ve built Phobos, an OpenTelemetry instrumentation plugin for Akka.NET, so we understand the low-level bits. Beyond that, we’ve been using OpenTelemetry in production for years on Sdkbin and we’ve helped over 100 customers implement OpenTelemetry configurations very similar to our own. Through all this experience, one thing has become crystal clear: the easiest, most production-ready approach to OpenTelemetry in .NET is using OTLP (OpenTelemetry Line Protocol) with a collector.
In this post, I’ll walk you through why this approach beats vendor-specific exporters every time, show you exactly how to configure it, and demonstrate the real-world benefits we’ve experienced at Petabridge. This is the companion piece to my recent YouTube video on the topic.
The Problem with Vendor-Specific Exporters
When you’re getting started with OpenTelemetry for the first time in one of your projects, you know your team uses DataDog, or New Relic, or Application Insights. So naturally, the first thing you’ll try is figuring out how to connect your application directly to that specific tool.
You end up with something that looks like this:
builder.Services .AddOpenTelemetry() .WithTracing(builder => { builder .AddHttpClientInstrumentation() .AddAspNetCoreInstrumentation() // Coupling our app to vendor-specific implementations .AddDatadogTracing() // Application code now depends on DataDog SDK .AddNewRelicTracing() // And New Relic SDK .AddAzureMonitorTracing(); // And Azure Monitor SDK });
And you’re going to get frustrated doing this because of:
- Vendor Coupling: Your application code is now directly coupled to vendor-specific SDKs...