Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was always turned down to use more Otel by how verbose it is and how heavy are the telemetry payload compared to simple adhoc alternatives.

Am I wrong?



The JavaScript Otel packages are implemented with 34 layers of extra abstraction. We wrote our own implementation of tracing for Cloudflare Workers and it performs much better with 0 layers of abstraction. I’ve seen a few other services switching over to our lightweight tracer. The emitted JSON is still chunky but removing all the incidental complexity helped a lot.


Can you share a link to your implementation?


It's private code in our monorepo

EDIT: we actually have two. The one we use for Node, the author plans to open source it eventually. That one is drop in replacement for Span and Trace classes and Just Works with upstream Otel. Main blocker is that we have some patch-package to fix other performance issues with upstream, and need to make our stuff work with non-patched upstream.

The one we use for Workers is more janky and doesn’t make sense to open source. It’s like 100 total LoC but doesn’t have compatibility with existing Otel libraries.


It is designed to get insights into dozen(s) connected systems.

It will always be overkill for just an app or two talking with eachother... till you grow, then it won't be overkill any more.

But still might be worth getting into it on smaller apps just thanks to wealth of tools available.


But my point is, especially for a big system, the performance impact of just the telemetry should be huge.


No, the spec isn't great and makes it hard to implement a performant solution.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: