Hacker News Reader

Comment by paulddraper | Hacker News Reader

Two problems with OpenTelemetry:

1. It doesn't know what the hell it is. Is it a semantic standard? Is a protocol? It is a facade? It is a library? What layer of abstraction does it provide? Answer: All of the above! All the things! All the layers!

2. No one from OpenTelemetry has actually tried instrumenting a library. And if they have, they haven't the first suggestion on how instrumenters should actually use metrics, traces, and logs. Do you write to all three? To one? I asked this question two years ago, zero answers :( [1]

[1] https://github.com/open-telemetry/opentelemetry-specificatio...

View on HN

1. Agreed. It's the sink and the house attached to it, and the docs are thin and confusing as a result.

2. I had a similar experience to you. I wanted to implement a simple heartbeat in our desktop app to get an idea of usage numbers. This is surprisingly not possible, which greatly confuses me given the name of the project. The low engagement on my question put me off and I abandoned my OpenTelemetry planning completely [1][2].

[1] https://github.com/open-telemetry/community/discussions/1598

[2] https://github.com/open-telemetry/semantic-conventions/issue...

Agreed. Some things they suggest aren't actually possible with their SDKs.

For example, you cannot define a histogram's buckets near where you define the histogram. You have to give the global exporter (or w/e the type is) a list of "overrides" that map each histogram name => their buckets. This makes it extremely ugly when you have libraries that emit metrics.

https://github.com/open-telemetry/opentelemetry-go/issues/38...

It's silent when you fuck up the selector too.

Actually it's silent pretty much all of the time. Very reminiscent of J2EE coding. Stare at the configs and hope for enlightenment.

Good deck of questions but I don't think they matter. I don't think those are answerable questions for observability, be it OpenTelemetry or other proprietary systems.

You can go read the leading observability companies web pages and they'll have a 4 page writeup on custom instrumentation. That's not much, just covers very elementary basics! It's not like OTel is behind. The answer just tends heavily towards "it depends."

Once you have experience - OTel or other - you can work through these things that might confound a neophyte.

The problem is they keep making the OTel tooling worse for working through these things, because the people writing the OTel tooling broadly aren't the people actually trying to monitor things. Even before OTel, plain Prometheus client libraries suffered from this.

All they had to do is maintain 3 json schema files.

They maintain a bunch of protobuf files, which is somewhat better and more efficient. You can still use json if you want.

Changing subject, love your work with ocaml.

Thank you ^_^

3. Does it scale?

Scale to what? We're generating >70k spans/sec and it's working fine. I'd say we're fairly medium size at best, though.

I totally read that with kubernetes in mind.

Reply on news.ycombinator.com