typelevel / typelevel/natchez

Move or Retire non-OpenTelemetry Modules?

Open
#695 4 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Scala
Stars
340
Forks
76
Avg merge
1d 6h
Merged PRs (30d)
13

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the repository's backend modules and the OpenTelemetry, Jaeger, Honeycomb, Lightstep, New Relic, DataDog, AWS X-Ray, OpenCensus, and OpenTracing references in the issue. The issue names no files or tests; done would require a decided migration, repository split, retirement, or documentation plan, followed by implementation and validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
scala
Domain
backend, observability
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.