What does HackerNews think of opentelemetry-specificatio?

There are a large amount of subtle tradeoffs around the bucketing scheme (log, vs. log-linear, base) and memory layout (sparse, dense, chunked) the amount of configurability in the histogram space (circllhist, DDSketch, HDRHistogram, ...). A good overview is this discussion here:

https://github.com/open-telemetry/opentelemetry-specificatio...

As for the circllhist: There are no knobs to turn. It uses base 10 and two decimal digits of precision. In the last 8 years I have not seen a single use-case in the operational domain where this was not appropriate.

A good place to look at is the milestones on GitHub: https://github.com/open-telemetry/opentelemetry-specificatio...

Logging is still experimental in the spec. Metrics API is feature freeze and the protocol is stable, so it's more on language SDKs to stabilize their implementations. This is a focus for several of them right now.

I think you are right and data model should have been event based rather than span based. https://medium.com/opentracing/open-for-event-based-tracing-... digs into that topic and basically says that distributed tracing is about causality & partial ordering which bring us back to the 70's with Lamport's logical clocks and all following work.

However, this design "flaw" is well known and seems assumed. I'm not able to find relevant GitHub issues right now, but I remember this topic being discussed on OpenTracing or OpenTelemetry bug tracker and the outcome was something like "Spans might not be the best data model, but people are now used to it and we have to ship the spec within a reasonable time, so let's stick to it".

Edit: https://github.com/open-telemetry/opentelemetry-specificatio... might be relevant to your concerns.

OpenMetrics relates to the metrics part of OpenTelemetry, where the latter is currently in alpha/experimental phase. OpenTelemetry has a statement on being interoperable with OpenMetrics for both accepting, forwarding and generating in the OpenMetrics format [0]. So they are two separate CNCF projects where OpenMetrics has overlap with a part of OpenTelemetry.

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

Indeed. For those unfamiliar, take a quick read of https://github.com/open-telemetry/opentelemetry-specificatio...

There are a few concepts to understand, but instrumenting it right from the start is valuable as it grows into a bigger system. Being a cross-cutting concern, the more code that standardizes on this the more useful it will be.

You can check the first link that states the overview - https://github.com/open-telemetry/opentelemetry-specificatio...

It's a distributed request tracing specification & set of libraries implementing the said spec

Here is the draft plan for logs: https://github.com/open-telemetry/opentelemetry-specificatio...

Logs are not going to be part of OpenTelemetry 1.0 release (only traces and metrics will). Logs are coming later (no specific timeline yet).

Disclaimer: I work on OpenTelemetry spec and wrote most of the linked doc. Comments/issues/PRs welcome in the repo.

I'm working on the OpenTelemetry JS project and i previously worked a bit on OpenCensus NodeJS.

The aim with both projects (OpenCensus/OpenTelemetry) is the same: having a open source implementation where you can change the exporter (to GCP,AWS,Zipkin,Jeager or anything you want) whenever you like. So Microsoft (or someone else having the API to report data to Azure) could totally implement an exporter for ApplicationInsights. Both projects have a specs [0][1] that are implemented in multiples languages.

Note: OpenTelemetry is just the project that resulted from the merging of OpenTracing and OpenCensus.

[0] https://github.com/census-instrumentation/opencensus-specs [1] https://github.com/open-telemetry/opentelemetry-specificatio...