Move or Retire non-OpenTelemetry Modules?

[bpholt]

As I was working on #688, I noticed that several of the backends supported here now actively encourage users to start with or switch to using OpenTelemetry instrumentation directly. Honeycomb, Jaeger, and Lightstep are all in this bucket. I get the impression NewRelic and DataDog would prefer you use their libraries (but they do support OTel). AWS X-Ray documents their OTel distro before their proprietary library, and present the choice in what seems like a pretty balanced way. And of course OpenCensus and OpenTracing merged to form OpenTelemetry, so their preference is clear as well.

It's also a little tricky to work on changes to core when every change has to be immediately propagated across all the backends. Since I have hands-on experience with OTel and X-Ray, it was straightforward enough to figure out the right way to implement #688, but the other backends have slightly different semantics, and I don't really have a good way of testing what happens when sending trace data to commercial services I don't use. It would be better to have maintainers for those modules who use them, who can implement new features as they come.

Maybe we should consider either (1) moving most of these backends to their own repositories, so they can be developed and versioned separately from the core and OTel backend, or (2) retiring them altogether if there's no maintainer interest in keeping them around. And either way, document clearly that new users should start with the OpenTelemetry backend unless they have a specific reason to use one of the others.

Of course, for existing codebases, migrating to a new instrumentation library may not be trivial, so dropping support altogether shouldn't be done lightly. It would be helpful to have download stats or other data to help make this decision, although if we start by moving backends to separate repos, there would at least be an opportunity for interested parties to continue maintenance.

So, I'm curious what the community thinks.

[armanbilge]

As Natchez stabilizes, schisming the monorepo is also a much better strategy for compatibility. So if an integration needs to make a breaking bump, it can do so without forcing core (and everyone else) to bump as well, or absorbing a break into a non-breaking version.

[Baccata]

We use datadog at $work. There are examples showcasing pure-scala integration with datadog (by using http to talk to to a deamon agent that is supposed to live on the same deployment as your application), without OT being involved :

• https://github.com/ovotech/natchez-extras
• https://github.com/trace4cats/trace4cats-datadog

I am set to implement my own natchez backend internally at $work (which is fairly easy) as I don't want to impose this maintenance to people here and I want to retain control over release cycles and version bumps.

So I personally would be fine with the natchez-datadog module being dropped.

[tpolecat]

OpenTelemetry didn't exist when Natchez started (and different back ends relied on different versions of OpenTracing) which is why there are so many distinct back ends. If OT is stable enough for use now then yeah we should transition.

[cartermp]

Just piping in here to say that OTel tracing is definitely stable enough. I can say that at least as far as Honeycomb is concerned, we ask all customers to start with opentelemetry instead of our proprietary stuff that came before it. I can't speak for other vendors, though.