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

Support for exposing /metrics and /healthz? #98

Open
dudicoco opened this issue Jan 15, 2020 · 5 comments
Open

Support for exposing /metrics and /healthz? #98

dudicoco opened this issue Jan 15, 2020 · 5 comments

Comments

@dudicoco
Copy link

Hi,

Does kube-metrics-adapter exposes its own metrics with a prometheus client? Does it expose an endpoint for health checks using kubernetes probes?

Thanks

@mikkeloscar
Copy link
Contributor

No, we currently don't provide either of those endpoints. What sort of metrics would you want to get from a prometheus endpoint?

@dudicoco
Copy link
Author

dudicoco commented Jan 15, 2020

Hi @mikkeloscar, I would like to get error counts within the controller so I can set up alerts accordingly.
I would also like a health endpoint so I can configure liveness probe checks to restart the container if it's unhealthy.
Here is an example of an implementation in the External-DNS controller:
kubernetes-sigs/external-dns#132 (comment)

@mikkeloscar
Copy link
Contributor

I guess it can make sense to report errors, e.g. if a collector is not working you could figure it out. maybe just a bit hard to distinguish between user configuration errors and actual errors in some cases.

PRs for adding such a metric endpoint would be welcome.

Regarding the health endpoint I'm not sure under which condition it would make sense to kill the container. Unlike external-dns, this is an active HTTP server so it definitely shouldn't have a separate listener for /healthz, but it could have one on the main listener and be used for readieness, though it's pretty much ready right away, anyway :)

@dudicoco
Copy link
Author

Thanks for the detailed explanation @mikkeloscar.

So if I set up a probe with https scheme to target the main listener i'm good to go?
Do you only recommend setting a readiness probe and not a liveness probe?

@mikkeloscar
Copy link
Contributor

We didn't run with either in production for a year or so now, and we didn't have issues related to this thus far, so I can't recommend on either as I don't know what the benefit would be :)

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

No branches or pull requests

2 participants