Otel - Pure Elixir implementation of OpenTelemetry

yangbancode

Hi everyone

I’d like to introduce Otel, a project I recently released — a pure-Elixir implementation of OpenTelemetry that satisfies the full OpenTelemetry Stable specification.

There’s still plenty to refine on the stability and performance side, but it’ll keep getting better — I hope it catches your interest.

Features

Signals

Traces

Metrics

Logs

Baggage

Propagators

W3C TraceContext

W3C Baggage

Exporters

Console (stdout)

OTLP HTTP

Configuration

Declarative YAML (OTEL_CONFIG_FILE)

Environment variables (OTEL_*)

Programmatic (Application env)

Semantic Conventions

Attribute registry

Metric registry

Integrations

:logger bridge

Thanks!

https://github.com/yangbancode/otel

7 comments

#library #open-telemetry

10 708 7

2026-04-29 18:29:36 UTC

Most Liked

Show Best Posts
Show All (oldest first)
Show All (newest first)

yangbancode

Hi @hauleth — I see you’re an OpenTelemetry core member. First, I want to sincerely thank you for the work and the community contribution you’ve put in over the years.

About five years ago, I introduced :opentelemetry Traces into a project I was working on, and it was a huge help for performance analysis and bug tracking. We surfaced and quickly resolved a number of issues that had been buried in the system, and that experience has stayed with me strongly ever since. Without the EEF team’s work at that time, I don’t think we would have unraveled those problems as quickly as we did.

Logs and Metrics weren’t officially supported back then, so I remember substituting :telemetry + Prometheus for Metrics and Logger JSON output + the Datadog Agent for Logs. It worked, but having those third-party tools hanging off :opentelemetry from every angle made for a less-than-smooth developer experience. I really wished all three signals would land in one place at stable quality, and I thought about contributing directly — but Erlang syntax never quite agreed with me. Quietly cheering from the user side was about all I could do.

After moving to a different company, I drifted away from :opentelemetry for a while. Recently I had a bit of free time and wanted to take on a fun personal project, and I was curious to actually try out what people are calling “vibe coding” with AI tools like Claude. I also wanted to get a feel for how I might work in the age of AI. While thinking about what topic would suit, the OpenTelemetry experience that had stayed with me most strongly came back to mind, and I thought — what if I tried implementing it myself?

In a sense, this project grew out of how amazing :opentelemetry felt to use back then — it’s not an attempt to replace the official implementation in any way. I started this as a small toy project to play with and run a few experiments, and I’d be grateful if it could be received in that spirit.

Post #4

mudasobwa

Creator of Cure

Woud you mind to tell, how is it better compared to opentelemetry?

Post #1

hauleth

Just from the start - your logger implementation will greatly impact performance of the whole system in case of slower exporter as you have no overload protection there.

And as @mudasobwa said - why create new project when there exists official one already?

Post #2

Last Post!

yangbancode

Hello @mudasobwa,

I took a look at the :telemetria library you recommended, and it really gave me some valuable insights.

My Otel project started out with the primary goal of catching up to the official OpenTelemetry spec as quickly as possible. So the initial design was similar to the official :opentelemetry project — implementing the core components (API, SDK, OTLP) as separate apps inside an umbrella and publishing them as individual packages.

However, since this project aims to be an all-in-one package that even beginners can pick up easily, I decided that a different direction from the official project would be the right fit. Think of it as something like minikube relative to Kubernetes. So for now, I’ve merged everything into a single application and shipped it that way.

For the next step, I’d been thinking I should focus more on the “user experience” rather than the “project structure,” and telemetria turned out to be a decisive hint in that direction. I think it’ll lead to some meaningful changes in where my project goes from here.

Thanks for the great inspiration!

Post #7