[tignaj]

Disclaimer: I work on OpenTelemetry specification and Collector.

It is true that the spec and libraries have been changing. This is to be expected since we haven't yet made a stable release. We are aiming for 1.0 GA release this year. The current plan is to freeze trace spec this week, followed by metric spec freeze in 3 weeks, followed by the release of several language implementations in 4 weeks after the spec freeze.

Like everyone else I wish we could release earlier, but the reality is that making dozens of companies agree on a standard takes time. I am very excited that we are approaching the finish line.

[tonyhb]

But it's been around for 5 years. First as opentracing (actually thanks Ben and LightStep!), then google decided to compete with opencensus (no thanks google), and now we have opentelemetry.

It's really, really, really annoying. After 5 years you might expect things to have calmed down. It was great at the start - like, actually. Even when baggage was rusty it had a direction and was usable. It probably still is, but the churn is crazy.

You say making dozens of companies agree is difficult, and yeah - it is - but thats because of other companies throwing out specs trying to compete with Lighttstep.

[harpratap]

This is not in competition to lightstep or any one vendor in particular. It is to converge all open source & proprietary solutions to follow a common spec and allow them to build on top of a common base.

OpenTracing dealt only with Tracing, it didn't care about logs or metrics. OpenCensus did all 3. This is combining the best of OpenTracing (which is Tracing) with idea that OpenCensus brought - just one library to collect and ship all the observability data that your application is supposed to emit.

[oaiey]

And like always when vendors / standards are built: It takes a while. Not surprised here.

[tonyhb]

On the fundamentals you agree with me: the goalposts shifted from telemtry to logging.

IMO they're different things. One deals with call graphs, timings, and associated baggage. The other is logs. Should we hold off on the spec for another 5 years and add datadog/prometheus metrics too?

I dont think that one spec should be all encompassing. Opentracing is great for tracing. Logs can be baggage. Memory use can be baggage. The temperature of the CPU and the current disk space is another platform altogether.

It's like saying everything in the world should run webassembly, and no other ISA matters. It's an idea! But, certainly a distraction from the benefits. Why not let tracing deal with tracing before messing with the 1.0?

[harpratap]

> the goalposts shifted from telemtry to logging

Telemetry has always included logging as one of it's components.

> Should we hold off on the spec for another 5 years and add datadog/prometheus metrics too?

I think you should look at OTel once again. OTel already includes metrics and supports exporting to Prometheus.

And I don't want to reply to the rest of your comments because I don't feel you understand this problem space enough before making such remarks on it.

[tonyhb]

Fair. I worked with Ben to integrate opentracing into docker before Kube won, and at that point it was tracing only. Tracing as in spans, annotations, and baggage spanning services. So, it has changed from call graphs/timing etc to telemetry in the broad sense.

We're talking about churn here, not my knowledge, and I think considering how you say I don't understand it we can both agree it has churned into something else. As OP said, there is a lot of churn. Too much for your common system to keep up with in the (pun intended) span of a couple years. 3 rebrands in fewer years isn't promising.