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.
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?
Otel is an Elixir library that ships Traces, Metrics, and Logs to an OTLP collector through a single dependency.
I started it to lower the barrier for Elixir developers — those not fluent in Erlang — stepping into OpenTelemetry for the first time.
They can pick it up casually at first, just to add observability to their applications. Later on, when they feel like looking under the hood to see how an OpenTelemetry SDK actually works at the code level, a pure-Elixir codebase should make a friendly guide.
Long term, once the official `:opentelemetry` ships all three signals as stable, they’ll be better off going with it — this project is an attempt to fill the gap until then. In the meantime, I hope they have fun playing with it like a small toy.
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.
One more bit of context, while I’m at it. I first met Erlang in my third year of CS undergraduate, moved to Elixir right after, and have spent the +10 years since working in Elixir exclusively — mostly in domains where stability and performance matter. So optimization is something I do have a feel for.
That said, this project was set up from the start as a vibe-coding experiment for me, so I’ve consciously avoided the traditional path of reviewing the code by hand to improve performance or quality. That kind of work I save for the production codebases at my day job.
What I’d like to explore here instead is how far raw model output can take a real codebase as AI models keep improving, and what kinds of context / environment setups developers can build around AI to push that further. So performance and code-quality observations from the community are genuinely useful as data points — though I should mention upfront that I likely won’t hand-fix them inside this repo.
When I rolled on my own telemetria, the main goal was to make it backend-agnostic and easily configurable. You might want to check it, too, for I dunno, ideas or like.
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.
