Thread by @mipsytipsy

Let's talk about OpenTelemetry, or "OTel", as the kids like to call it.

I remember emitting sooo many frustrated twitter rants back in 2017-2018 about how *behind* we were as an industry when it comes to standards for instrumentation and logging.

Then OTel shows up.

For those of you who have been living under a rock, OTel is an open standard for generating, collecting, and exporting telemetry in a vendor agnostic way.

Before OTel, every vendor had its own libraries, and switching (or trying out) new vendors was a *bitch*.

Yeah, it's a bit more complicated to set up than your standard printf or logging library, but it also adds more discipline and convenience around things like tracing and the sort of arbitrarily-wide structured data blobs (bundled per request, per event) that o11y requires.

In terms of investment, it's one of the best things any platform team can do to make their code maintainable over the long run.

And since you can switch from vendor to vendor without reinstrumenting (!), it forces vendors to compete on the merits instead of relying on lock-in.

Or that's the theory, at least. That's why Honeycomb went all-in on OTel. honeycomb.io/blog/all-in-on… Lightstep, NewRelic, and many other vendors have also put their chips on the table with OTel.

It's better for everyone. In theory.

So what happens if one of the biggest players in the space decides to have it both ways, by treating OTel as a one way street? they'll "support" it, but only as a bridge for new users to get data in to their own walled garden?

DataDog has been telling users they can use OTel to get data in, but not get data out.

The DataDog OTel collector PR was silently killed. github.com/open-telemetry… The person who wrote it appears to have been pressured into closing it, and nothing has been proposed to replace it.

Behind the scenes, we've heard from our customers (who are also DataDog customers) that they have been downplaying the maturity of OTel and discouraging people from using it.

They push you towards their locked-in proprietary integrations, saying it's not ready for prime time.

They say it's "unstable, with breaking changes" and point to the fact that it isn't 1.0 yet.

Nonsense. We've been running it in prod for over a year now, and so have tons of customers. Go look for yourself -- the repo isn't exactly a backlog of hipri breaking tickets. 🙄

Not to mention, the integrations were **based on datadog integrations** in the first place! (at their insistence).

The reason that OTel collector isn't marked fully stable is that the team reserves the right to break INTERNAL APIs between OTel collector components.

All that means is that vendors (like us) have to update some APIs when we build new collector distros. If you're a normal end user who uses the collector packages, you'll never notice.

And the language SDKs have been GA for over a year now. It's a total scare campaign.

Here is the DataDog post from 2.5 years ago, tooting the horn about donating their tracing integrations to OTel. datadoghq.com/blog/opentelem…

Yes, these are the same integrations they are now darkly warning users to stay away from, because they "aren't stable."

I don't usually call competitors out by name. But this isn't a "honeycomb vs datadog" thing. There are dozens of vendors adopting or supporting OTel on your behalf.

As far as we can tell, DataDog is the only one pulling this kind of shady shit to keep users locked in.

And ultimately that's what matters. We support OTel because that's what's in the best interest of our users. It's in *your* best interest.

Even if you're a very happy DataDog customer who never plans to leave -- and there are lots of those! -- you should care about this.

I've got no argument with companies who want to continue to publish and promote non-OTel integrations.

But if you support the open standard to let people get their data in, you should support the open standard to let people get their data out. Or you're just an asshole.