-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Clarify internal usage of empty label values by federation #2530
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: alexgreenbank <[email protected]>
Signed-off-by: alexgreenbank <[email protected]>
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.
See my comment. I think to really clarify #11024, we should also add a paragraph to the documentation of the external_labels
config setting, explaining the (limited) use cases where you want an empty label there.
@@ -128,6 +128,8 @@ Label names beginning with "__" are RESERVED for system usage and SHOULD NOT be | |||
|
|||
Remote write Receivers MAY ingest valid samples within a write request that otherwise contains invalid samples. Receivers MUST return a HTTP 400 status code ("Bad Request") for write requests that contain any invalid samples. Receivers SHOULD provide a human readable error message in the response body. Senders MUST NOT try and interpret the error message, and SHOULD log it as is. | |||
|
|||
Whilst [Federation](https://prometheus.io/docs/prometheus/latest/federation/) relies upon an `instance` label with an empty value this is strictly an internal use case. Everything else MUST adhere to the `MUST NOT contain any empty label names or values` requirement above. |
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 wondering if the federation use case would ever lead to the necessity to send an empty label value via remote write.
In different news, I think the most common case of utilizing an empty instance
label is actually the Pushgateway and not federation. (The Pushgateway even adds an empty instance
label implicitly, see last paragraph of this doc section.)
But again, this is only relevant for exposition and subsequent scrape, not for remote write. The samples ingested via federation or from a Pushgateway won't have any empty labels anymore when sent via remote write.
So maybe let's take it from a different perspective:
Whilst [Federation](https://prometheus.io/docs/prometheus/latest/federation/) relies upon an `instance` label with an empty value this is strictly an internal use case. Everything else MUST adhere to the `MUST NOT contain any empty label names or values` requirement above. | |
The existing use cases for empty label names (mostly when scraping a [federation endpoint](https://prometheus.io/docs/prometheus/latest/federation/) or the [Pushgateway](https://github.com/prometheus/pushgateway?tab=readme-ov-file#about-the-job-and-instance-labels) with the `honor_labels: true` setting) are irrelevant for remote write and thus not in conflict with the “MUST NOT contain any empty label names or values” requirement above. |
Just checked: So federation also adds an empty |
Ref: prometheus/prometheus#11024
Attempt to clarify the existing usage of empty label values by the federation system.
More details of that use case here: prometheus/prometheus#8726 (comment)
The goal of adding this line to the documentation is to point out the internal exception to the "MUST NOT contain any empty label names or values." rule and reinforce that it should not be relied upon anywhere else.