Add info function blog post #2780
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Owen Williams <[email protected]>
aknuds1
reviewed
Nov 18, 2025
Comment on lines
+16
to
+18
| In Prometheus, a set of labels on a metric is always considered "identifying", which means that when Prometheus sees any change in any label, it considers that data to be part of a new and distinct metric series. For example, the data associated with "cluster=prod-1" is distinct from data associated with "cluster=prod-2". However, in practice, some labels are "non-identifying", such as "pod ID." One service could be rescheduled on a different pod, and although the pod ID changes, the user may consider this as the same data stream as what came before and would prefer to treat it as a contiguous series. Today in Prometheus, these would show up as separate series, requiring aggregations on volatile labels. | ||
|
|
||
| The `info()` function helps make this separation explicit by separating labels into two buckets: those on the metric itself (identifying) and those on the target_info metric (non-identifying). When a query is run, the value of labels provided by `info()` can change over time, but the response will appear as a single, non-interrupted series, without the need for further `sum()` aggregations. The question of whether a label is "identifying" -- whether it indicates a distinct series or not -- can vary between installations and is controlled by the user. |
Contributor
There was a problem hiding this comment.
I don't really think this makes sense, sorry.
It's true that metric labels are always identifying in Prometheus, but in the specific context of joining with info metrics and calling info, a subset is considered identifying. With regards to the target_info metric, the instance and job labels are the identifying subset.
Identifying labels in this particular context are exactly like foreign keys in SQL, you need to know that instance and job are the labels to join on (unless you use info, because it hides that detail).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
is this accurate?
Signed-off-by: Arve Knudsen [email protected]<!--
Please sign CNCF's Developer Certificate of Origin and sign-off your commits by adding the -s / --sign-off flag to
git commit-->