How to map the Meter name in non-OTLP exporters? #1906
Assignees
Labels
area:semantic-conventions
Related to semantic conventions
spec:metrics
Related to the specification/metrics directory
Comments
arminru
added
area:sdk
|
I think this old discussion is related: #434 |
|
Metric exporters suffer more greatly from limited attribute labels vs. tracing. If we specify that this CAN be reported, it's ok. If we specify it MUST be reported, we're causing problems for our users. Specifically, for fields the "vary" a lot. Here's a good article on prometheus-related issues, and evaluation of alternative metric tsdbs I think requiring instrumentation library version MAY be a bit too far for a prometheus ecosystem, but the library name might be ok. Point being Labels for Metrics need more care than they did for Trace, and we should evaluate appropriately. |
|
@jsuereth Making the name a SHOULD or CAN is fine with me. For the version we could add some guidance that it might be unnecessary in most situations but still define the attribute key so it's used consistently in case someone decides to report it. |
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 19, 2021
* Add `OTEL_METRICS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 19, 2021
* Add `OTEL_METRICS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 21, 2021
* Add `OTEL_METRICS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 21, 2021
* Add `OTEL_METRICS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 21, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 21, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 23, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 23, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 25, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 25, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
|
The Metrics SDK part is addressed by #2040. There is also the semantic convention part and Prometheus Exporter part, so keep the issue open. |
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 25, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 26, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_LIBRARY_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 27, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_ADD_METER_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
hdost
added a commit
to criteo-forks/opentelemetry-specification
that referenced
this issue
Oct 27, 2021
* Add `OTEL_EXPORTER_PROMETHEUS_ADD_METER_ATTRIBUTES` variable * Update Metric SDK to clarify when Meter attributes should be exported. Fixes open-telemetry#1906 Signed-off-by: Harold Dost <h.dost@criteo.com>
|
Note that with #2276 the attribute keys for the tracer name will be changed to |
This was referenced Jul 28, 2022
tigrannajaryan
pushed a commit
that referenced
this issue
Oct 12, 2022
Fixes: #2493 Related: #1906 This is a second attempt at #2422. ## Changes ### Background: Naming Collisions OpenTelemetry encourages the use of semantic conventions to make metric naming similar across instrumentation. For example, if I have two http client libraries in my application, they would each produce a metric named `http.client.duration`, but with different meters (e.g. [otelmux](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/github.com/gorilla/mux/otelmux) vs [otelhttp](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/net/http/otelhttp)). A prometheus exporter which receives both of these metrics would not be able to serve both of those histograms. This would occur anytime a user uses two libraries which produces the same category (e.g. http, database, rpc, etc) of metrics, or if the two libraries just happen to use the same name for a metric. Depending on the language, it may fail to create the Prometheus exporter, or may fail to send some, or all metrics if the same labels keys and values are present in both. ### Desired User Experience As a user, I can use a Prometheus exporter with OpenTelemetry without experiencing strange errors/behavior due to naming collisions, and without having to apply transformations to metric names to work around these, except in rare cases. As a user, I can easily add scope attributes to my metrics in Prometheus by joining with an info-style metric. This is a common pattern in Prometheus: https://grafana.com/blog/2021/08/04/how-to-use-promql-joins-for-more-effective-queries-of-prometheus-metrics-at-scale/. ### Design Add `opentelemetry_scope_name` and `opentelemetry_scope_version` as labels to all metrics. This ensures that if two libraries produce the same metric points, they don't collide because the scope name/version labels will differ. Those labels also serve as "join keys" to be able to add scope attributes to Prometheus metrics. This is accomplished by introducing an `opentelemetry_scope_info` metric containing the same `opentelemetry_scope_name` and `opentelemetry_scope_version` labels, but also including scope attributes. This also enables the collector's Prometheus receiver to reconstruct the original Instrumentation Scope when receiving the metrics.
ChengJinbao
added a commit
to ChengJinbao/opentelemetry-specification
that referenced
this issue
Nov 16, 2022
Fixes: #2493 Related: open-telemetry/opentelemetry-specification#1906 This is a second attempt at open-telemetry/opentelemetry-specification#2422. ## Changes ### Background: Naming Collisions OpenTelemetry encourages the use of semantic conventions to make metric naming similar across instrumentation. For example, if I have two http client libraries in my application, they would each produce a metric named `http.client.duration`, but with different meters (e.g. [otelmux](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/github.com/gorilla/mux/otelmux) vs [otelhttp](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/net/http/otelhttp)). A prometheus exporter which receives both of these metrics would not be able to serve both of those histograms. This would occur anytime a user uses two libraries which produces the same category (e.g. http, database, rpc, etc) of metrics, or if the two libraries just happen to use the same name for a metric. Depending on the language, it may fail to create the Prometheus exporter, or may fail to send some, or all metrics if the same labels keys and values are present in both. ### Desired User Experience As a user, I can use a Prometheus exporter with OpenTelemetry without experiencing strange errors/behavior due to naming collisions, and without having to apply transformations to metric names to work around these, except in rare cases. As a user, I can easily add scope attributes to my metrics in Prometheus by joining with an info-style metric. This is a common pattern in Prometheus: https://grafana.com/blog/2021/08/04/how-to-use-promql-joins-for-more-effective-queries-of-prometheus-metrics-at-scale/. ### Design Add `opentelemetry_scope_name` and `opentelemetry_scope_version` as labels to all metrics. This ensures that if two libraries produce the same metric points, they don't collide because the scope name/version labels will differ. Those labels also serve as "join keys" to be able to add scope attributes to Prometheus metrics. This is accomplished by introducing an `opentelemetry_scope_info` metric containing the same `opentelemetry_scope_name` and `opentelemetry_scope_version` labels, but also including scope attributes. This also enables the collector's Prometheus receiver to reconstruct the original Instrumentation Scope when receiving the metrics.
joaopgrassi
pushed a commit
to dynatrace-oss-contrib/semantic-conventions
that referenced
this issue
Mar 21, 2024
Fixes: #2493 Related: open-telemetry/opentelemetry-specification#1906 This is a second attempt at open-telemetry/opentelemetry-specification#2422. ## Changes ### Background: Naming Collisions OpenTelemetry encourages the use of semantic conventions to make metric naming similar across instrumentation. For example, if I have two http client libraries in my application, they would each produce a metric named `http.client.duration`, but with different meters (e.g. [otelmux](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/github.com/gorilla/mux/otelmux) vs [otelhttp](https://github.com/open-telemetry/opentelemetry-go-contrib/tree/0dd27453a1ce8e433cb632e175a27f28ee83998d/instrumentation/net/http/otelhttp)). A prometheus exporter which receives both of these metrics would not be able to serve both of those histograms. This would occur anytime a user uses two libraries which produces the same category (e.g. http, database, rpc, etc) of metrics, or if the two libraries just happen to use the same name for a metric. Depending on the language, it may fail to create the Prometheus exporter, or may fail to send some, or all metrics if the same labels keys and values are present in both. ### Desired User Experience As a user, I can use a Prometheus exporter with OpenTelemetry without experiencing strange errors/behavior due to naming collisions, and without having to apply transformations to metric names to work around these, except in rare cases. As a user, I can easily add scope attributes to my metrics in Prometheus by joining with an info-style metric. This is a common pattern in Prometheus: https://grafana.com/blog/2021/08/04/how-to-use-promql-joins-for-more-effective-queries-of-prometheus-metrics-at-scale/. ### Design Add `opentelemetry_scope_name` and `opentelemetry_scope_version` as labels to all metrics. This ensures that if two libraries produce the same metric points, they don't collide because the scope name/version labels will differ. Those labels also serve as "join keys" to be able to add scope attributes to Prometheus metrics. This is accomplished by introducing an `opentelemetry_scope_info` metric containing the same `opentelemetry_scope_name` and `opentelemetry_scope_version` labels, but also including scope attributes. This also enables the collector's Prometheus receiver to reconstruct the original Instrumentation Scope when receiving the metrics.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the Tracing SDK spec we have specified the following mapping for the Tracer name and version (= InstrumentationLibrary name/version) for non-OTLP exporters:
The Metrics API specifies the Meter name and version accordingly. In OTLP this is reported as
InstrumentationLibraryas well.Should we define the same mapping for non-OTLP metrics exporters as well, i.e., should the meter name and version be added as attributes/labels/tags/dimensions called
otel.library.nameandotel.library.version, or would it make more sense to call thisotel.meter.*here? This would be inconsistent with the Tracing spec, however, since that one could have also just called itotel.tracer.*but didn't.I'd be in favor of staying consistent here, even though seeing
otel.library.*on the backend might not be as obvious to the user as the more "tangible" notation of a "Meter name".The text was updated successfully, but these errors were encountered: