-
Notifications
You must be signed in to change notification settings - Fork 2.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
feat compact: added readiness Prober #1297
Conversation
25100a8
to
f91182c
Compare
@bwplotka Formerly we discussed:
I chose compact as a first one since it should be most straight forward :) |
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 besides one nit
cmd/thanos/main.go
Outdated
@@ -73,7 +75,7 @@ func main() { | |||
registerStore(cmds, app, "store") | |||
registerQuery(cmds, app, "query") | |||
registerRule(cmds, app, "rule") | |||
registerCompact(cmds, app, "compact") | |||
registerCompact(cmds, app, component.Compact) |
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 know that you have not introduced this parameter but I feel that in the long term this parameter should go away and we should just use component.Compact
inside of the function itself since it is already designated for registering the compact
command 😄
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.
Sounds good to me, I thought about it too but I wasn't sure even with this change.
If we agree I'll be happy to change it. PR like this will come for every component so eventually I can change it for all of them.
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.
changed in 127ee71 is this ok with you?
Oh, and could we update |
@GiedriusS I knew I forgot about something, thanks for reminding me! 😄 Ill modify those manifests too. |
@GiedriusS manifests should be fixed now PTAL |
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!
Thanks. Minor 2 nits only.
cmd/thanos/compact.go
Outdated
func registerCompact(m map[string]setupFunc, app *kingpin.Application, name string) { | ||
cmd := app.Command(name, "continuously compacts blocks in an object store bucket") | ||
func registerCompact(m map[string]setupFunc, app *kingpin.Application) { | ||
component := component.Compact |
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.
const component = component.Compact
?
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.
hm it looks like struct or any other more complex data structure cannot be a constant IIUC?
I renamed the variable at least to comp
so it does not collide with the package name.
127ee71
to
67fbcc6
Compare
thanks @bwplotka for the cr! |
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.
So we are setting healthy when we start listening for metrics and ready when initialization finishes?
I think for compact we should set ready and healthy after initialization finishes. As for compact ready isn't important as it isn't serving traffic, so we actually only care about healthy.
Thoughts?
Yes, the healthy status is set by the The readiness is left there just so it is somewhere. As you said in case of compactor it does not matter. IIUC you would move setting healthiness to the same place as readiness? IMHO this would not change anything since the server is not listening yet so setting healthy before it starts has no meaning and just would require to take out the generic liveness setting from the |
I think we should just remove readiness, it doesn't make sense in compactor and we shouldn't expose it. Users should just use healthy. WDYT? |
TBH I'd rather leave it there. All other components will hopefully have it and user could be confused that it's missing. I'd just say it's ready right from the start? But if you prefer removing it I'll make it disappear :) |
I agree let's leave it in. This makes helm / deployment logic simpler. Standards reduce cognitive load :-) |
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 and I agree with the comments. Could we fix up the CHANGELOG.md
changes so that it would go under the relevant section before merging this? Plus you have some merge conflicts :)
0ad706e
to
129035b
Compare
@GiedriusS should be rebased now with all the conflicts resolved and changelog entry adjusted as well. Sorry for the delay |
129035b
to
ed91fdb
Compare
hm.. weird. retriggered the CI and it passed and before it failed on Azure tests. |
Signed-off-by: Martin Chodur <m.chodur@seznam.cz>
ed91fdb
to
55ebdb6
Compare
LGTM, @bwplotka could you make the final call here in light of comments by Povilas? |
@GiedriusS I agree let's reduce cognitive load and keep it ;) |
Regarding
I would still set readiness and healthiness in the same place if possible, to reduce the cognitive burden on developers. But other than that LGTM |
* master: iter.go: error message typo correction (thanos-io#1376) Fix usage of $GOPATH in Makefile (thanos-io#1379) Moved Prometheus 2.11.1 and TSDB to 0.9.1 (thanos-io#1380) Store latest config hash and timestamp as metrics (thanos-io#1378) pkg/receive/handler.go: log errors (thanos-io#1372) receive: Hash-ring metrics (thanos-io#1363) receiver: avoid race of hashring (thanos-io#1371) feat compact: added readiness Prober (thanos-io#1297) Add changelog entry for S3 option (thanos-io#1361) Multipart features (thanos-io#1358) Added katacoda.yaml (thanos-io#1359) Remove deprecated option from example (thanos-io#1351) Move suggestion about admin API to appropriate place (thanos-io#1355)
Great, thanks for the review and merging this! I'll start with PR for next thanos component to add the prober |
Changes
Used new Prober package in the Thanos compact to provide
/-/healthy
and/-/ready
endpointsI also added new
defatltHTTPListener
which registers the prober. I'm leaving the oldmetricHTTPListenGroup
withTODO
to remove it once all components are migrated to the new one to avoid touching different components in this PR.Also I switched to using
component.Component
instead of passing the string from the main.It felt weird to have somewhere string and somewhere the component interface.
Verification
Tested it and works as expected, also exposes metrics about Prober status