2 ms·
There is very much an alternative. Looking at the execution of your code should never alter its fundamental performance the way otel is built to do. This was a
by kchoudhu 11mo ago
There is very much an alternative. Looking at the execution of your code should never alter its fundamental performance the way otel is built to do. This was a solved problem at least a decade and a half ago, but the cool kids decided to reinvent the wheel, poorly.
https://news.ycombinator.com/item?id=45845889 https://news.ycombinator.com/item?id=45845889
- PunchyHamster 11mo agodtrace was meant for entirely different use, and it's not a replacement for otel Otel was made to basically track the request execution (and anything that request triggers) across multiple apps at once, not to instrument an app to find slow points
- nothrabannosir 11mo agoTo OP’s credit though the latter is exactly what every single piece of otel documentation pushes you to do. Using only the manual spans api is an exercise in api docs spelunking and ignoring “suggested best practices” and “only do this if everything else has failed for you”.
- kchoudhu 11mo agoWe should be using USDTs to emit trace ids that can be consumed by dtrace and shoved into whatever backend we want for tracing.
- csomar 11mo agoThat's just one dimension to telemetry. For my use case, for example, I need distributed tracing; which is a fancy word for correlated logs.