[h1fra]

Tracing is much more actionnable but barely usable without a platform. Which makes local programming dependent on third party. Also it requires passing context or have a way to get back the context in every function that requires it, which can be daunting.

On my side I have opted to mixed structured/text, a generic message that can be easily understood while glancing over logs, and a data object attached for more details.

[hinkley]

Someone got me excited about tracing and I started tweaking our stats API to optionally add tracing. Retrofitted it into a mature app, then immediately discovered that all of the data was being dropped because AWS only likes very tiny traces. Depth or fanout or both break it rather quickly.

And OpenTelemetry has a very questionable implementation. For a nested trace, events fire when the trace closes, meaning that a parent ID is reported before it is seen in the stream. That can’t be good for processing. Would be better to have a leading edge event (also helps with errors throwing and the parent never being reported).

Kind of a bummer. Needs work.

[pcthrowaway]

> OpenTelemetry has a very questionable implementation

The nice thing about OpenTelemetry is that it's a standard. The questionable implementation you're referencing isn't a source of truth. There isn't some canonical "questionable" implementation.

There are many, slightly different, questionable implementations.

[hinkley]

If the wire protocol has a bug, that’s not something an implementation can fix.

I’m saying the wire protocol is wrong.

[candiddevmike]

You can add Jaeger to your local dev containers and run it in memory, it's really lightweight and easy to use.