-
Notifications
You must be signed in to change notification settings - Fork 0
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
Metrics endpoint #56
Comments
Seems a better option is the https://samsaffron.com/archive/2018/02/02/instrumenting-rails-with-prometheus |
Done some initial work on this here: https://github.com/mysociety/foi-for-councils/compare/prometheus-metrics Running Then after starting the Rails will be accessible at http://0.0.0.0:3000/ |
Looks cool, I'll spin this up and have a look. |
This looks pretty good! We'll need to be able to configure the port for the collector in the final app in case we need to run multiple collectors for different services on the same host, but that's simple enough. We'll need to consider labels, too. I'll have a bit of a think about this but my first thought in production would be to use the vhost name as the job, we can then aggregate multiple instances this way but also slice them on instance if needed (in production, instance will be fqdn:port, not localhost:port). None of this is needed for testing, of course. I've got a couple of minor changes to suggest for the bootstrapping process, one general one for the |
@sagepe has suggested integrating with an Prometheus server which can collect basic application metrics from an
/metrics
endpoint.Their Ruby client gem [1] provides middleware to do just this.
[1] https://github.com/prometheus/client_ruby
The text was updated successfully, but these errors were encountered: