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

Metrics endpoint #56

Open
gbp opened this issue Apr 24, 2018 · 4 comments
Open

Metrics endpoint #56

gbp opened this issue Apr 24, 2018 · 4 comments
Labels

Comments

@gbp
Copy link
Member

gbp commented Apr 24, 2018

@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

@gbp gbp added the 1 - new label Apr 24, 2018
@gbp
Copy link
Member Author

gbp commented Apr 24, 2018

Seems a better option is the prometheus_exporter gem.

https://samsaffron.com/archive/2018/02/02/instrumenting-rails-with-prometheus

@gbp
Copy link
Member Author

gbp commented Apr 24, 2018

Done some initial work on this here: https://github.com/mysociety/foi-for-councils/compare/prometheus-metrics

Running vagrant up should install and configure prometheus so it knows about the Rails app and to start automatically on boot.

Then after starting the rails server and prometheus_exporter using foreman (vagrant ssh then bundle exec foreman start -p 3000) everything else required should be running.

Rails will be accessible at http://0.0.0.0:3000/
Prometheus will be accessible at http://0.0.0.0:9090/

@sagepe
Copy link
Member

sagepe commented Apr 24, 2018

Looks cool, I'll spin this up and have a look.

@sagepe
Copy link
Member

sagepe commented Apr 25, 2018

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 Vagrantfile which I'll make separately and another change to the provisioning script to use systemctl - I'll add this as a commit to this branch.

@gbp gbp removed the 1 - new label Apr 27, 2018
@sagepe sagepe mentioned this issue May 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants