-
Notifications
You must be signed in to change notification settings - Fork 9.7k
PROM-39: Add type and unit labels to OTLP endpoint #16630
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
Conversation
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 think some refactoring would be of help (same as Copilot suggests). Also, shouldn't there be a flag for enabling this new behaviour?
47f49b0
to
fed77d1
Compare
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.
Pull Request Overview
This PR implements support for adding type and unit labels to OTLP metrics. Key changes include the addition of a typeAndUnitLabels flag in both the test cases and the OTLP write handler, updates to various metric conversion functions to emit these new labels, and corresponding test updates.
- Introduces a new flag (typeAndUnitLabels) to conditionally add type and unit labels.
- Updates test cases and converter functions to include the new labels when enabled.
- Adjusts helper functions and metadata handling for consistent label creation.
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
storage/remote/write_test.go | Updated test cases to include typeAndUnitLabels flag and expected label values. |
storage/remote/write_handler.go | Added new OTLPOptions flag and propagated it to handler configuration. |
storage/remote/otlptranslator/prometheusremotewrite/number_data_points.go | Modified gauge and sum data point functions to append type and unit labels. |
storage/remote/otlptranslator/prometheusremotewrite/metrics_to_prw.go | Updated metric metadata usage for consistent label injection. |
storage/remote/otlptranslator/prometheusremotewrite/histograms.go & helper.go | Updated histogram conversion functions and introduced helper addTypeAndUnitLabels for label creation. |
storage/remote/otlptranslator/prometheusremotewrite/number_data_points.go
Outdated
Show resolved
Hide resolved
storage/remote/otlptranslator/prometheusremotewrite/number_data_points.go
Outdated
Show resolved
Hide resolved
It is supposed to be behind the feature gate added in #16228. Your question made me realize that I haven't updated |
11ff522
to
1758891
Compare
@carrieedwards FYI this might be of interest |
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.
Pull Request Overview
This PR implements the addition of type and unit labels to incoming OTLP metrics. Key changes include propagating a new flag (AddTypeAndUnitLabels) through the Options, API, and OTLP write handler, updating the conversion functions to attach the new labels, and augmenting test cases to cover scenarios both with and without type/unit label injection.
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
web/web.go | Added new flag AddTypeAndUnitLabels to Options and passed it along during handler construction. |
web/api/v1/api.go | Propagated the new boolean flag to the OTLP write handler initialization in the API setup. |
storage/remote/write_handler.go | Extended OTLPOptions and rwExporter to include the type and unit labels flag. |
storage/remote/write_test.go | Updated tests to include the new typeAndUnitLabels parameter and expected label changes. |
Various otlptranslator files | Updated conversion logic to use new metadata format and attach type and unit labels when configured. |
cmd/prometheus/main.go | Enabled the experimental flag for type and unit labels via command-line configuration. |
labels = append(labels, prompb.Label{Name: "__type__", Value: strings.ToLower(metadata.Type.String())}) | ||
labels = append(labels, prompb.Label{Name: "__unit__", Value: metadata.Unit}) |
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.
Consider extracting the label key strings "type" and "unit" into constants to ensure consistency and ease future maintenance.
labels = append(labels, prompb.Label{Name: "__type__", Value: strings.ToLower(metadata.Type.String())}) | |
labels = append(labels, prompb.Label{Name: "__unit__", Value: metadata.Unit}) | |
labels = append(labels, prompb.Label{Name: typeLabelKey, Value: strings.ToLower(metadata.Type.String())}) | |
labels = append(labels, prompb.Label{Name: unitLabelKey, Value: metadata.Unit}) |
Copilot uses AI. Check for mistakes.
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 agree with Copilot that it would be nice to have constants for these, analogously to how we have a __name__
constant.
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'd like to do so once a new version of Common is released with this patch
@@ -518,6 +527,14 @@ func createLabels(name string, baseLabels []prompb.Label, extras ...string) []pr | |||
return labels | |||
} | |||
|
|||
// addTypeAndUnitLabels appends type and unit labels to the given labels slice if the setting is enabled. | |||
func addTypeAndUnitLabels(labels []prompb.Label, metadata prompb.MetricMetadata) []prompb.Label { | |||
labels = append(labels, prompb.Label{Name: "__type__", Value: strings.ToLower(metadata.Type.String())}) |
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.
Consider checking whether a label with the name "type" (and similarly "unit") already exists in the labels slice before appending, to avoid potential duplication.
Copilot uses AI. Check for mistakes.
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 think this copilot comment is worth looking into - is there a possibility that the user adds a __type__
label to their series and then this additional __type__
label is also added?
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.
Hmmm interesting, I just tried doing that myself and got a big error on my face "Invalid label for series. Duplicated label: xxxxx". This is coming from the prwv1 appender.
Thanks for paying extra attention here
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 think we should be overwriting the type and unit labels if they do exist, to be consistent with the proposal:
Generally clients should never expose type and unit labels directly as it's a special label starting with
__
. However, it can happen by accident or intentionally to support ingestion methods without metadata fields (e.g. PRW 1.0). That's why any existing user provided labels for__unit__
and__type__
should be overridden by the existing metadata mechanisms in current exposition and ingestion formats, otherwise we keep them on.
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.
Fixed!
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.
Please see comments.
labels = append(labels, prompb.Label{Name: "__type__", Value: strings.ToLower(metadata.Type.String())}) | ||
labels = append(labels, prompb.Label{Name: "__unit__", Value: metadata.Unit}) |
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 agree with Copilot that it would be nice to have constants for these, analogously to how we have a __name__
constant.
I won't be able to work on this until June 25th 😬 @carrieedwards, @dashpole, @bwplotka -- If you happen to have the time, feel free to continue! If not, I'll do it once I'm back :) |
I'm going to try and pick this up |
Superseded by #16770 |
After a few discussions with David and the rest of the OTel-Prometheus working group, I'm reopening this PR. Migrating the ingestion path from RWv1 to RWv2 is not as beneficial as expected. |
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.
one comment around possible duplicate metadata labels, otherwise looks good
@@ -518,6 +527,14 @@ func createLabels(name string, baseLabels []prompb.Label, extras ...string) []pr | |||
return labels | |||
} | |||
|
|||
// addTypeAndUnitLabels appends type and unit labels to the given labels slice if the setting is enabled. | |||
func addTypeAndUnitLabels(labels []prompb.Label, metadata prompb.MetricMetadata) []prompb.Label { | |||
labels = append(labels, prompb.Label{Name: "__type__", Value: strings.ToLower(metadata.Type.String())}) |
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 think this copilot comment is worth looking into - is there a possibility that the user adds a __type__
label to their series and then this additional __type__
label is also added?
The conflicts should go away once #16878 is merged |
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.
LGTM
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>
Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> 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>
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>
11e806e
to
b83b0bc
Compare
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.
Pull Request Overview
This PR implements the addition of __type__
and __unit__
labels to OTLP metrics when receiving OTLP data. The feature is controlled by a new configuration option that can be enabled via the "type-and-unit-labels" feature flag, which affects both scraping and OTLP ingestion.
- Adds a new
AddTypeAndUnitLabels
configuration option that flows through the web handler to the OTLP translator - Implements label addition functionality that appends metric type and unit information as special labels
- Updates all affected function signatures to pass metadata instead of just metric names to support the new labeling feature
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
web/web.go | Adds AddTypeAndUnitLabels option to web handler configuration |
web/api/v1/api.go | Updates API constructor to accept and pass through the new configuration parameter |
web/api/v1/errors_test.go | Updates test to provide required parameter for API constructor |
storage/remote/write_handler.go | Implements OTLP handler configuration and passes setting to translator |
storage/remote/write_test.go | Adds comprehensive test cases for both enabled and disabled type/unit label scenarios |
storage/remote/otlptranslator/prometheusremotewrite/metrics_to_prw.go | Updates translator to use metadata objects and conditionally add type/unit labels |
storage/remote/otlptranslator/prometheusremotewrite/number_data_points.go | Modifies number data point handling to support new labeling feature |
storage/remote/otlptranslator/prometheusremotewrite/histograms.go | Updates histogram handling for new labeling functionality |
storage/remote/otlptranslator/prometheusremotewrite/helper.go | Implements core addTypeAndUnitLabels function and updates related functions |
storage/remote/otlptranslator/prometheusremotewrite/helper_test.go | Adds unit tests for the new label addition functionality |
cmd/prometheus/main.go | Enables the feature for both scraping and OTLP when feature flag is set |
Comments suppressed due to low confidence (1)
storage/remote/write_test.go:454
- The expected metric name has changed from "test_counter_total" to "test_counter_bytes_total" but there's no test case to verify the unit is properly included in the metric name when type and unit labels are disabled. Consider adding a test case that explicitly verifies unit inclusion in metric names.
l: labels.New(labels.Label{Name: "__name__", Value: "test_counter_bytes_total"},
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.
Mainly I think there should be consistent terminology for this feature between scraping and remote write subsystems. Also, I would like to avoid the code duplication introduced by this PR.
storage/remote/otlptranslator/prometheusremotewrite/metrics_to_prw.go
Outdated
Show resolved
Hide resolved
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.
LGTM!
f235f68
to
9d04e0a
Compare
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
9d04e0a
to
05925a5
Compare
Comments resolved, so I'm merging! |
* PROM-39: Add type and unit labels to OTLP endpoint Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Extract label addition into helper function Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Wire feature flag and web handler configuration Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Apply suggestions from code review Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Use lowercase for units too Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Use otlptranslator.UnitNamer to build units Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Address copilot's comment Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Verify label presence before adding them Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Overwrite type/unit labels when already set Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * sed/addTypeAndUnitLabels/enableTypeAndUnitLabels/ Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Reduce duplicated code Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> --------- Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>
* PROM-39: Add type and unit labels to OTLP endpoint Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Extract label addition into helper function Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Wire feature flag and web handler configuration Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Apply suggestions from code review Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Use lowercase for units too Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Use otlptranslator.UnitNamer to build units Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Address copilot's comment Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Verify label presence before adding them Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Overwrite type/unit labels when already set Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * sed/addTypeAndUnitLabels/enableTypeAndUnitLabels/ Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> * Reduce duplicated code Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> --------- Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com> Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Signed-off-by: Andrew Hall <andrew.hall@grafana.com>
Part of #16610
Implements the addition of
__type__
and__unit__
labels when receiving OTLP metrics.