-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat: Add timezone to kube_cronjob_info / Make kube_cronjob_next_schedule_time timezone-aware #2376
Open
mrueg
wants to merge
2
commits into
kubernetes:main
Choose a base branch
from
mrueg:cronjob-add-timezone
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
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.
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.
wouldn't it be better in its own metric rather than in the info metric?
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.
There's a 1:1 relationship, why would you prefer a dedicated metric for it?
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.
@dgrisonnet any feedback 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.
_info
is not a very intuitive suffix which is why I don't really like these metrics where we just end up dumping a bunch of labels that aren't really related between one another.I don't know what was the historical reasoning for putting labels into these metrics, but I can also see some dedicated metrics for values part of objects spec:
kube-state-metrics/internal/store/pod.go
Lines 1212 to 1231 in 569e820
To me, info should be limited to the default labels. Any other information that we want to expose should be in its own dedicated metric. What is your opinion on that?
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 on having a separate metric for anything that does not have a 1:n relationship within the object. For 1:1 relationships, additional time series make it difficult to correlate between multiple labels vs. simply extracting the ones you need:
max(resource_info) by (label1, label2, label3)
.Trying to do the same with multiple metrics can get very annoying and more error-prone.
To me, the _info metric should describe all single-value keys of the object that are static over its lifetime and non-numeric.
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.
Hmm, there seems to be a naming discrepancy between per-property gauges and per-object info metrics, so there's no clear pattern we can adhere to.
That being said, accumulating all cardinally-bound fields as label-sets into a per-object
_info
metric opens the room for metrics with a large number of labels. The metric itself can grow to become unintentionally cardinal and dropping unwanted labels will entail relabelling efforts. Splitting this into per-field metrics will limit the cardinality and allow for a more granular control.Users should be able to add the timezone label to any exported metric using a
foo_metric * on(job) group_left(timezone) kube_cronjob_timezone
.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 tried to define it here:
the _info metric should describe all single-value keys of the object that are static over its lifetime and non-numeric
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 meant a documentation/standard of sorts in the repository that enforces this. Not sure if there is one.
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 can add that in a follow-up PR.