-
Notifications
You must be signed in to change notification settings - Fork 922
Prometheus translation modes #4533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Prometheus translation modes #4533
Conversation
- `UnderscoreEscapingWithSuffixes`, the default. This fully escapes metric names for classic Prometheus metric name compatibility, and includes appending type and unit suffixes. | ||
- `NoUTF8EscapingWithSuffixes` will disable changing special characters to `_`. Special suffixes like units and `_total` for counters will be attached. | ||
- `NoTranslation`. This strategy bypasses all metric and label name translation, passing them through unaltered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prometheus already also has UTF8 with suffixes, we should list that here for permutation completeness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it really? I can't see it in the code 🤔
A Prometheus Exporter MAY support a configuration option to produce metrics without a [unit suffix](../../compatibility/prometheus_and_openmetrics.md#metric-metadata) | ||
or UNIT metadata. The option MAY be named `without_units`, and MUST be `false` by default. | ||
A Prometheus Exporter MAY support a configuration option that controls the translation of metric names from OpenTelemetry Naming Conventions to [Prometheus Naming conventions](https://prometheus.io/docs/practices/naming/). | ||
If the Prometheus exporter supports such configuration it MUST be named `translation_strategy`, and the translation options MUST be: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should enforce the configuration name with MUST, esp because the without_units configuration option MAY be named that as indicated below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if we're understanding each other here 🤔
I'm adding a MUST for the configuration name to ensure consistency between Prometheus and OTel SDKs and Collector components. That was our goal here, right?
The without_unit
existed before this change and was used to control both suffix addition and the inclusion of UNIT metadata. The change I'm proposing is that without_unit
doesn't control suffix addition anymore, just the metadata inclusion
For example: | ||
|
||
- If configured with `NoTranslation` but the client requests `escaping=underscores`, the exporter MUST apply underscore escaping | ||
- If configured with `UnderscoreEscapingWithSuffixes` but the client `escaping=allow-utf8`, there's no need to revert what has been translated since the SDK will continue to be compliant. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love this clarification!
Folks, I'm out until June 25th. @ywwg is picking this up while I'm gone :) I've removed the draft mode to help Owen with his notification settings |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
not stale |
(it won't let me remove the stale label) |
## Changes Addressing feedback received during the last Spec SIG meeting, I'm splitting my previous PR(#4533) into two to ensure we keep the scope of the original one for the configuration changes. If I understand correctly, almost all SDKs (if not all) are already compliant since they are wrappers around Prometheus SDKs, and Prometheus SDKs already do content negotiation properly. Then the PoCs are already done :) * [X] Related issues #4494 * [ ] Links to the prototypes (when adding or changing features) * [x] [`CHANGELOG.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/CHANGELOG.md) file updated for non-trivial changes * [ ] [`spec-compliance-matrix.md`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md) updated if necessary --------- Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> Co-authored-by: Reiley Yang <reyang@microsoft.com> Co-authored-by: David Ashpole <dashpole@google.com>
…tion Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
…ddition Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Co-authored-by: David Ashpole <dashpole@google.com>
Co-authored-by: David Ashpole <dashpole@google.com>
591044a
to
e8ee790
Compare
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
The CI failure seems unrelated. Could someone re-trigger it? 😇 |
Related to #4494
Changes
This change focuses on three things:
The goal is to mimic Prometheus' existing configuration that controls the translation of metric names when receiving OTLP metrics via its /otlp endpoint. Configuration alignment will help users migrate in both directions (Prometheus/Collector) when switching their metrics collection systems.
Additional Information
Some further reading might be helpful for reviewers:
CHANGELOG.md
file updated for non-trivial changesspec-compliance-matrix.md
updated if necessary