This comment was the first thing to explain that it's better logging. That's actually something I'd be interested in, running several different datascience services/analyses, logging was something I implemented then gave up on because it sucks so much. You're losing a lot of potential players because you have given 0 effort to explaining in simple terms what you are. A "From logging to telemetry" primer would probably garner you a lot more interest.
https://opentelemetry.io/about/
But I agree this is a better explanation :)
I still don't get how trances/spans are shared across rpc boundaries but I know that's a thing one can do.
When it gets back to you and all spans are merged, you can see the whole picture, but don't need to provide all the details all the way down.
Trace - One unique id for an "action", say customer purchasing an item. A set of spans exist under a trace.
Span - An interval with a start time and duration. Can add tags for querying. Can add logs for richer information but not indexed. Each span belongs to exactly one trace.
Baggage - key value pairs you can pass between services. They aren't tagged as part of the span or trace, but the receiving service can use these values to make decisions or add them to its local spans as logs or spans.
Under the hood, it's just a set of HTTP headers passed between services. The first span creates a trace id and passes that to all downstream services as a header.
Each service independently pushes it's span data into a centralised collector which indexes the data and exposes it over an UI/API.
OpenTelemetry provides a specification and some reference implementation across languages.
At least, this is my understanding of it. I've dabbled with Jaegar but I'm not affiliated with any of these.