-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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 track_timestamps_staleness limit to CRDs #6105
feat: add track_timestamps_staleness limit to CRDs #6105
Conversation
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
// When true, Prometheus ignores the timestamps for all the targets created | ||
// from service and pod monitors. | ||
// Otherwise the TrackTimestampsStaleness field of the service or pod monitor applies. | ||
OverrideTrackTimestampsStaleness bool `json:"overrideTrackTimestampsStaleness,omitempty"` |
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.
Quick question.
Do we see any use cases where Prometheus admin wants to override the decision made by the scrape config?
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.
Thanks for your review.
When OverrideTrackTimestampsStaleness
is set to "true" for Job target, it will be inserted in the TSDB when the target is down.
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 that it's something that the Prometheus admin cares about (there's an bit of resource overhead for tracking the staleness but it's probably negligible). In the first implementation, I'd focus only on the service/pod monitor part.
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.
@nicolastakashi @simonpasquier Is it necessary to retain the OverrideTrackTimestampsStaleness
global configuration?🤔
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 would keep it simple and drop it for now.
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.
From my understanding we can remove it for now and focus only on svc/pod monitor as @simonpasquier mentioned.
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.
Thanks @simonpasquier @nicolastakashi , PTAL
Drop the OverrideTrackTimestampsStaleness
global configuration.
Cool! |
// When true, Prometheus ignores the timestamps for all the targets created | ||
// from service and pod monitors. | ||
// Otherwise the TrackTimestampsStaleness field of the service or pod monitor applies. | ||
OverrideTrackTimestampsStaleness bool `json:"overrideTrackTimestampsStaleness,omitempty"` |
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 that it's something that the Prometheus admin cares about (there's an bit of resource overhead for tracking the staleness but it's probably negligible). In the first implementation, I'd focus only on the service/pod monitor part.
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Co-authored-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: dongjiang1989 <dongjiang1989@126.com>
@simonpasquier addressed comments, please review :) |
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.
Just a few nits for consistency in the doc comments. Otherwise this looks good!
@@ -626,6 +626,10 @@ | |||
} | |||
}, | |||
"type": "object" | |||
}, | |||
"trackTimestampsStaleness": { | |||
"description": "`trackTimestampsStaleness` defines whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. \n It requires Prometheus >= v2.48.0.", |
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.
"description": "`trackTimestampsStaleness` defines whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. \n It requires Prometheus >= v2.48.0.", | |
"description": "`trackTimestampsStaleness` defines whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. Has no effect if `honorTimestamps` is false. It requires Prometheus >= v2.48.0.", |
@@ -1550,6 +1550,10 @@ | |||
} | |||
}, | |||
"type": "object" | |||
}, | |||
"trackTimestampsStaleness": { | |||
"description": "TrackTimestampsStaleness whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. Has no effect if `honorTimestamps` is false. It requires Prometheus >= v2.48.0.", |
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.
"description": "TrackTimestampsStaleness whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. Has no effect if `honorTimestamps` is false. It requires Prometheus >= v2.48.0.", | |
"description": "`trackTimestampsStaleness` defines whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. Has no effect if `honorTimestamps` is false. It requires Prometheus >= v2.48.0.", |
@@ -651,6 +651,10 @@ | |||
} | |||
}, | |||
"type": "object" | |||
}, | |||
"trackTimestampsStaleness": { | |||
"description": "TrackTimestampsStaleness whether Prometheus tracks staleness of the metrics that have an explicit timestamps present in scraped data. Has no effect if `honorTimestamps` is false. \n It requires Prometheus >= v2.48.0.", |
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.
"description": "TrackTimestampsStaleness whether Prometheus tracks staleness of the metrics that have an explicit timestamps present in scraped data. Has no effect if `honorTimestamps` is false. \n It requires Prometheus >= v2.48.0.", | |
"description": "`trackTimestampsStaleness` defines whether Prometheus tracks staleness of the metrics that have an explicit timestamp present in scraped data. Has no effect if `honorTimestamps` is false. It requires Prometheus >= v2.48.0.", |
@@ -207,6 +207,15 @@ type PodMetricsEndpoint struct { | |||
// +optional | |||
HonorTimestamps *bool `json:"honorTimestamps,omitempty"` | |||
|
|||
// TrackTimestampsStaleness whether Prometheus tracks staleness of | |||
// the metrics that have an explicit timestamps present in scraped data. |
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.
// the metrics that have an explicit timestamps present in scraped data. | |
// the metrics that have an explicit timestamp present in scraped data. |
@@ -207,6 +207,15 @@ type PodMetricsEndpoint struct { | |||
// +optional | |||
HonorTimestamps *bool `json:"honorTimestamps,omitempty"` | |||
|
|||
// TrackTimestampsStaleness whether Prometheus tracks staleness of |
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.
// TrackTimestampsStaleness whether Prometheus tracks staleness of | |
// `trackTimestampsStaleness` defines whether Prometheus tracks staleness of |
@@ -438,6 +438,14 @@ type Endpoint struct { | |||
// +optional | |||
HonorTimestamps *bool `json:"honorTimestamps,omitempty"` | |||
|
|||
// `trackTimestampsStaleness` defines whether Prometheus tracks staleness of | |||
// the metrics that have an explicit timestamp present in scraped data. |
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.
// the metrics that have an explicit timestamp present in scraped data. | |
// the metrics that have an explicit timestamp present in scraped data. | |
// Has no effect if `honorTimestamps` is false. |
@@ -135,6 +135,13 @@ type ScrapeConfigSpec struct { | |||
// HonorTimestamps controls whether Prometheus respects the timestamps present in scraped data. | |||
// +optional | |||
HonorTimestamps *bool `json:"honorTimestamps,omitempty"` | |||
// TrackTimestampsStaleness whether Prometheus tracks staleness of |
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.
// TrackTimestampsStaleness whether Prometheus tracks staleness of | |
// `trackTimestampsStaleness` whether Prometheus tracks staleness of |
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.
Thanks!
I'm not dismissing the latest comments from @jan--f but they can be addressed in a follow-up PR :) |
Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
ref: prometheus/prometheus#13060
add track_timestamps_staleness limit to CRDs
Type of change
What type of changes does your code introduce to the Prometheus operator? Put an
x
in the box that apply.CHANGE
(fix or feature that would cause existing functionality to not work as expected)FEATURE
(non-breaking change which adds functionality)BUGFIX
(non-breaking change which fixes an issue)ENHANCEMENT
(non-breaking change which improves existing functionality)NONE
(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)Changelog entry
Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.