Comment by deathanatos

The OpenTelemetry spec is a mess. There's so much … abstract blah blah blah? … and very little actual details.

If I actually go to the part of the spec that I think gets down to "here is how to concretely write OpenTelemetry stuff [1], that seems to have the various attributes camelCased, for example, whereas the article has named them "spanID" and "traceID".

AFAICT the "spec" also just links you to the implementation. "Just" read this protobuf definition, translate that to JSON in your mind's eye. I "POST" this to a hard-coded path tacked onto a URL… but do I post individual traces/logs? Can I batch them? I'm sure there's a gRPC thing I could start guessing from…

But it seems like the JSON stuff is a second class citizen from the gRPC interface. Unless that's just as bad, too…

Actually getting set up in Python isn't too terrible, though there are a few classes that you're like "what's the point of this?" and most of them are apparently just undoc'd. (E.g., [2], ^F TraceProvider, get nothing.)

It is a bit depressing how this seems to be becoming The Chosen Spec.

I also sort of have 64-bit integers for span IDs (TFA never mentions it, but AFAICT this is required by spec). I'd much rather have "/span/ids/are/a/tree" span IDs, as this integrates much better with any logging system: I can easily ask my log viewer to filter to a specific span (span_id == "/spans/a/b/c") or to a subtree (span_id regex-matches /^\/spans\/a\/.*/)

(And the spec bizarrely focuses on some sort of language-abstract API, instead of … actual data types / media types?)

[1]: https://opentelemetry.io/docs/specs/otlp/#otlphttp

[2]: https://opentelemetry-python.readthedocs.io/en/latest/api/tr...