How to convert telemetry to opentelemetry

I have a lot of libraries which emit telemetry events, and I’d like to covert them into OpenTelemetry spans. I’ve found the opentelemetry_telemetry library, but examples there do not work and it looks heavily outdated, without proper documentation, plus :telemetry doesn’t allow attaching to event by prefix, so I have to write some strange and hacky code to translate spans from one library to another.

It would be nice if anyone could share their experience here, thanks!

1 Like

Tricky subject, but I wouldn’t say that the telemetry library itself has any notion of spans? It’s main purpose is dynamic dispatch, and maybe some specific library emits events that are aware of spans :thinking:

Are you looking for some way to reduce code boilerplate that can be found in libraries like these ones from opentelemetry-erlang-contrib?

If you look at libraries like OpenTelemetryOban you can see that the common pattern is to create :telemetry hooks that then initiate open telemetry spans. This allows you to stick with the more general purpose telemetry library while also enabling people who use open telemetry to get otel spans out.


I thought so too, but it turns out that telemetry.span generates unique span context in metadata for every span, so it is possible to convert a telemetry span to opentelemetry span.

1 Like

Yeah, I’ve seen it, and just took a look again, but it feels really annoying to write the same boilerplate for something which telemetry.span already does out of the box. I want a solution where every span from telemetry is automatically exported in an opentelemetry format. And I don’t see any limitations for this solution, do you?

The limitation is that if someone wants to get spans from your library and export them to say app signal they have to convert otel spans to app signal spans which is a lot heavier weight than regular telemetry spans to app signal spans.

End users of your library that aren’t doing otel will end up pulling in a bunch of dependencies as well.

You got me wrong. I am not suggesting writing telemetry in otel always. I am suggesting to have a relay which automatically converts all telemetry spans to otel spans, and as far as I can see, there are no limitations for this, but still, every opentelemetry_* library writes this boilerplate from scratch

1 Like

The first point about AppSignal is a good one But there are not a “bunch of dependencies” that will be pulled in . A library should only depend on opentelemetry_api which itself has 0 dependencies :slight_smile:

I’m not sure what trouble you’re having here. The bridge library is up to date and used by probably half of our instrumentation libraries. Perhaps you could elaborate here or pop into opentelemetry on the Elixir Slack for help.

I want to automatically convert telemetry span events to opentelemetry spans. I know that the generic solution is possible, but I can’t implement it yet with the knowledge I have right now

It is possible but it has additional requirements. There is no way to try to create spans from every possible event in the system without a mechanism to register the events.

Please note, this undocumented experimental functionality is being removed from this library so do not rely on it.

1 Like
  1. It is undocumented (as stated in the original post)
  2. Why is it being removed?
  3. And why do you suggest it then?

It’s being removed because it was an experiment and relies on widespread adoption of registry which has not occurred. I did not suggest using it, I was merely providing an example of how it can conceivably be achieved.

I get this, so there is no way to automatically convert telemetry span events (manually specified or with telemetry_registry) to opentelemetry spans.

There is unimplemented suggestion and deprecated undocumented function.

I’d like to help with this issue, but I don’t have any free time to learn opentelemetry and write the code. I am just a user who doesn’t want to attach numerous opentelemetry libraries just to get what is already emitted in telemetry.

I would expect a compiler author like you to be more performance-minded so it’s a mystery to me why would you even want a translation layer. That’s not sustainable. Not to mention that it becomes a convenience you wouldn’t be willing to let go of if you author that translation layer, meaning that those libraries will be less and less likely to ever use OpenTelemetry as time goes by (and it seems OTel is not going anywhere, that’s why I bet on it in my work).

Maybe I could interest you with mentioning semgrep or comby with which you can formulate queries nailing all the pieces of your code that would need migration and then use good old sed or awk to change stuff around?

Sure, it might not be just “search and replace”, I get that, but it could be a good start.

Might be an interesting project I think.

And you suggest doing this for every dependency I have? Ha-ha)

I think the best solution is to have relay translating spans from telemetry to opentelemetry format. Or just telemetry exporter which converts events to opentelemetry format.

Yes. As mentioned, OTel is here to stay. So might as well migrate, it could be the perfect time for that.