Skip to content
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

Merged
merged 1 commit into from
Aug 5, 2019

Conversation

FUSAKLA
Copy link
Member

@FUSAKLA FUSAKLA commented Jul 2, 2019

Changes

Used new Prober package in the Thanos compact to provide /-/healthy and /-/ready endpoints

I also added new defatltHTTPListener which registers the prober. I'm leaving the old metricHTTPListenGroup with TODO 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

# HELP thanos_prober_healthy Represents health status of the component Prober.
# TYPE thanos_prober_healthy gauge
thanos_prober_healthy{component="compact"} 1
# HELP thanos_prober_ready Represents readiness status of the component Prober.
# TYPE thanos_prober_ready gauge
thanos_prober_ready{component="compact"} 1

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 2, 2019

@bwplotka
So first one of the series of Prober additions 🎉

Formerly we discussed:

  • Naming of the defaultHTTPListener
  • If the default listener should
    • set healthy
    • set ready

I chose compact as a first one since it should be most straight forward :)

Copy link
Member

@GiedriusS GiedriusS left a 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

CHANGELOG.md Outdated Show resolved Hide resolved
@@ -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)
Copy link
Member

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 😄

Copy link
Member Author

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.

Copy link
Member Author

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?

@GiedriusS
Copy link
Member

Oh, and could we update tutorials/kubernetes-demo/manifests/thanos-compactor.yaml so that it would use these new end-points according to this https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/? 😍

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 2, 2019

@GiedriusS I knew I forgot about something, thanks for reminding me! 😄 Ill modify those manifests too.

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 2, 2019

@GiedriusS manifests should be fixed now PTAL

Copy link
Member

@bwplotka bwplotka left a 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/main.go Outdated Show resolved Hide resolved
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const component = component.Compact?

Copy link
Member Author

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.

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 11, 2019

thanks @bwplotka for the cr!

Copy link
Member

@povilasv povilasv left a 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?

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 16, 2019

Yes, the healthy status is set by the defaultHTTPListener right from the time when the /-/healthy endpoint is available which happen to be the same time we start to listen for metrics.

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 defaultHTTPListener. But maybe I'm missing out something?

@povilasv
Copy link
Member

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?

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 25, 2019

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 :)

@midnightconman
Copy link
Contributor

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 :-)

Copy link
Member

@GiedriusS GiedriusS left a 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 :)

@FUSAKLA FUSAKLA force-pushed the fus-compact-prober branch 3 times, most recently from 0ad706e to 129035b Compare July 29, 2019 21:13
@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 29, 2019

@GiedriusS should be rebased now with all the conflicts resolved and changelog entry adjusted as well. Sorry for the delay

@FUSAKLA
Copy link
Member Author

FUSAKLA commented Jul 30, 2019

hm.. weird. retriggered the CI and it passed and before it failed on Azure tests.
seems to be somehow flaky :/

Signed-off-by: Martin Chodur <m.chodur@seznam.cz>
@GiedriusS
Copy link
Member

LGTM, @bwplotka could you make the final call here in light of comments by Povilas?

@povilasv
Copy link
Member

povilasv commented Aug 5, 2019

@GiedriusS I agree let's reduce cognitive load and keep it ;)

@povilasv
Copy link
Member

povilasv commented Aug 5, 2019

Regarding

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 defaultHTTPListener. But maybe I'm missing out something?

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

@GiedriusS GiedriusS merged commit 4cf32d0 into thanos-io:master Aug 5, 2019
paulfantom added a commit to paulfantom/thanos that referenced this pull request Aug 7, 2019
* 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)
@FUSAKLA
Copy link
Member Author

FUSAKLA commented Aug 7, 2019

Great, thanks for the review and merging this!

I'll start with PR for next thanos component to add the prober

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants