Initial cut at migrating jmacd's datamodel document into the spec #1512
Conversation
jsuereth
changed the title
Co-authored-by: Aaron Abbott <aaronabbott@google.com>
Co-authored-by: Reiley Yang <reyang@microsoft.com>
Co-authored-by: Reiley Yang <reyang@microsoft.com>
…th/opentelemetry-specification into metric-data-model-initial
| - With delta temporality: stateless collector | ||
| - With cumulative temporality: stateful collector | ||
| 6. OTel SDK exports directly to 3P backend | ||
| 7. OTel SDK exports directly to 3P backend |
There was a problem hiding this comment.
(Is "3P" defined somewhere?)
There was a problem hiding this comment.
I would replace with the explicit text :)
| - With delta temporality: stateless collector | ||
| - With cumulative temporality: stateful collector | ||
| 6. OTel SDK exports directly to 3P backend | ||
| 7. OTel SDK exports directly to 3P backend |
There was a problem hiding this comment.
I would replace with the explicit text :)
| - Using OTLP as an intermediary format between two non-compatible formats | ||
| - Importing [statsd](https://github.com/statsd/statsd) => Prometheus PRW | ||
| - Importing [collectd](https://collectd.org/wiki/index.php/Binary_protocol#:~:text=The%20binary%20protocol%20is%20the,some%20documentation%20to%20reimplement%20it) | ||
| => Prometheus PRW | ||
| - Importing Prometheus endpoint scrape => [statsd push | collectd | opencensus] | ||
| - Importing OpenCensus "oca" => any non OC or OTel format | ||
| - TODO: define others. |
There was a problem hiding this comment.
I think I fail a bit to understand this:
It is in scope to have Prometheus -> OTLP -> PRW and it is in scope to have StatsD -> OTLP then why is not in scope to have StatsD -> OTLP -> PRW? mathematically if the translation function OTLP -> PRW is defined and StatsD -> OTLP is defined then I can compose them to get StatsD -> OTLP -> PRW
There was a problem hiding this comment.
I think StatsD -> OTLP -> PRW is in-scope. We haven't added support for raw sampled metric events, which is how they appear to the StatsD receiver, so somewhere in that picture is a stateful conversion to OTLP(cumulative) which is not a difficult task, just requires memory.
I believe there is an additional concept that belongs in the specification, and I'm sorry to introduce it here, that I think of as a counterpart to the Single-Writer definition we have discussed. It can be called a Single-Reader property, and it is required to perform a correct delta-to-cumulative translation.
Single-Reader: Having access to the whole stream of data for a metric. This happens when an OTel collector is configured as a per-node agent and every process on the node reports through that agent. This happens when an OTel collector pool runs the Kafka exporter and Kafka receiver with appropriate configuration.
StatsD -> OTLP -> PRW should be in-scope for a single-node deployment, and it ought to behave just as https://github.com/prometheus/statsd_exporter would.
There was a problem hiding this comment.
@bogdandrutu There's a lot of nuance to Statsd => PRW. While TECHNICALLY you can shove bits into PRW, when I say "compatibility" i mean the way we defined it for Prometheus: "A user of prometheus shouldn't be able to tell if OTLP was used to transport prometheues style metric to their backend". Similarly, for users of Statsd today, we should HONOR the statsd conventions and formats from statsd => PRW. The reason Statsd => PRW is out of scope is because of all the non-data-related nuance (e.g. naming conventions, namespace options etc. that a statsd user would expect).
To be frank: I don't think it's OTLP's job to define how Statsd maps into PRW, and we shouldn't sacrifice the design of OTLP for that use case. We can attempt to provide the best translation possible, but it should not "block" or otherwise inhibit progress. There's a difference between "out of scope" and "can't do". What I'm suggesting is we won't prioritize or make a ton of effort to solve statsd => PRW bugs that are inherent to the impedance mismatch of those two models.
@jmacd I'm actually tying your "Single-Reader" into the "SingleWriter rule. Specifically the way I'm phrasing Single-WRiter in the not-yet-public PR is that any given timeseries should originate from a --SingleWriter. This includes aggregation time series, meaning if the collector is manipulating a metrics, it becomes the new single-writer of that aggregation. It is also required for delta-to-cumulative manipulation (which in my opinion, that's a new series of data). To some extent I think this nuance is just terminology and we need to make sure we COVER the instance of when it's OK to do "Delta-Cumulative" and what that implies on your telemetry-pipeline architecture.
There was a problem hiding this comment.
💯
It is also required for delta-to-cumulative manipulation (which in my opinion, that's a new series of data).
Yes, that's how I've been thinking about it too. It's permitted to output the same metric name, in this case, because the incoming data is "terminal".
| - Using OTLP as an intermediary format between two non-compatible formats | ||
| - Importing [statsd](https://github.com/statsd/statsd) => Prometheus PRW | ||
| - Importing [collectd](https://collectd.org/wiki/index.php/Binary_protocol#:~:text=The%20binary%20protocol%20is%20the,some%20documentation%20to%20reimplement%20it) | ||
| => Prometheus PRW | ||
| - Importing Prometheus endpoint scrape => [statsd push | collectd | opencensus] | ||
| - Importing OpenCensus "oca" => any non OC or OTel format | ||
| - TODO: define others. |
There was a problem hiding this comment.
I think StatsD -> OTLP -> PRW is in-scope. We haven't added support for raw sampled metric events, which is how they appear to the StatsD receiver, so somewhere in that picture is a stateful conversion to OTLP(cumulative) which is not a difficult task, just requires memory.
I believe there is an additional concept that belongs in the specification, and I'm sorry to introduce it here, that I think of as a counterpart to the Single-Writer definition we have discussed. It can be called a Single-Reader property, and it is required to perform a correct delta-to-cumulative translation.
Single-Reader: Having access to the whole stream of data for a metric. This happens when an OTel collector is configured as a per-node agent and every process on the node reports through that agent. This happens when an OTel collector pool runs the Kafka exporter and Kafka receiver with appropriate configuration.
StatsD -> OTLP -> PRW should be in-scope for a single-node deployment, and it ought to behave just as https://github.com/prometheus/statsd_exporter would.
jsuereth
moved this from Written Specification
to Done
in Spec - Metrics Data Model and Protocol
…en-telemetry#1512) * Initial cut at migrating Josh MacD's datamodel document into the specification. Co-authored-by: Aaron Abbott <aaronabbott@google.com> Co-authored-by: Reiley Yang <reyang@microsoft.com> Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
From Task: https://github.com/open-telemetry/opentelemetry-specification/projects/3#card-56227942
Note: This PR is 100% focused on framing the problem with the 3 models and separation of concerns, as well as defining some key use cases for evaluating the model.
Replaces #1510 with permission to do so.