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 same metrics endpoints as nomad and consul #5223

Closed
uepoch opened this issue Aug 29, 2018 · 4 comments
Closed

Support same metrics endpoints as nomad and consul #5223

uepoch opened this issue Aug 29, 2018 · 4 comments

Comments

@uepoch
Copy link
Contributor

uepoch commented Aug 29, 2018

Is your feature request related to a problem? Please describe.
Support for pulled metrics has been added in other Hashi's products
Having to log in the machine to SIGUSR in order to have human readable metrics available is painful
There's no friendly way to display metrics right now
with statsd protocol, there's no control from the monitoring software side about the frequency/precision/aggregation of time series

Describe the solution you'd like
Support a v1/sys/metrics (unauth or auth, not sure what is best)
That either dumps the metrics from inMemSink in JSON or support format=prometheus in query params
(Exact same behavior as nomad and consul)

Describe alternatives you've considered
The only valid option is to use statsd right now, as circonus is not part of the monitoring team stack

Explain any additional use-cases
Consul had support added for Prometheus in late April
Prometheus is a quite standard solution today and supports labeling
This would allow users to quickly check metrics about a vault server running in dev environments

**Additional context

We are using statsd now, and (probably because of misconfigured things) ended up with graphite vs statsd not being synchronised thus producing empty chunks of time series quite often.
Used it for consul before our PR hashicorp/consul#4014 was merged

After reading #2937 #1230 and #1415, I was wondering if Hashi changed its mind about adding metrics handler as you now support it on other projects.
Dumping text from the prom registry does not seem big and could fit in a 30 lines function given the use of expfmt if the networking code is a problem

What do you think ?

@jefferai
Copy link
Member

No minds have been changed, the issue with Prometheus is specific to the way they require building in a listener to Vault just to run their own custom code.

This sounds totally fine, PR would be even more welcome :-D

@uepoch
Copy link
Contributor Author

uepoch commented Aug 30, 2018

Ok, I will start working on it then !

@Dudesons
Copy link

Hi @uepoch @jefferai,
just to be informed do you think the pull request #5308 will be merged or another solution will be chosen ?
There is an eta for the support of prometheus endpoint ?
The integration with statsd is painful to build great dashboard and alerting.
There is a way to allow vault to push metrics to pushgateway (it's not recommended but it's maybe betterthan statsd)

@catsby
Copy link
Contributor

catsby commented Nov 8, 2019

Hello! I'm going to close this issue now as #5308 was merged. Thank you!

@catsby catsby closed this as completed Nov 8, 2019
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

4 participants