4 ms·
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?
by greatgib 1y ago
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?
- MrBuddyCasino 1y agoNo, the spec isn't great and makes it hard to implement a performant solution.
- PunchyHamster 1y agoIt 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.
- greatgib 1y agoBut my point is, especially for a big system, the performance impact of just the telemetry should be huge.
- jitl 1y agoThe 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.
- mvf4z7 1y agoCan you share a link to your implementation?
- jitl 1y agoIt'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.