# Instrumenting Rails with Prometheus

DevFeed: [Instrumenting Rails with Prometheus](<https://devfeed.tech/articles/instrumenting-rails-with-prometheus-41344.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2018/02/02/instrumenting-rails-with-prometheus>)

Author: Sam Saffron

Published: 2018-02-02T02:45:30Z

Content type: tutorial

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [Prometheus](<https://devfeed.tech/topics/prometheus.md>), [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>), [Processes](<https://devfeed.tech/topics/processes.md>)

Tags: [http](<https://devfeed.tech/tags/http.md>), [instrumentation](<https://devfeed.tech/tags/instrumentation.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [process](<https://devfeed.tech/tags/process.md>), [prometheus](<https://devfeed.tech/tags/prometheus.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>)

## AI overview

This tutorial explains the challenges of exposing Prometheus metrics from Rails applications running multiple forked processes. It introduces the prometheus_exporter gem, which aggregates metrics across processes and exposes them to Prometheus through a dedicated HTTP endpoint.

## Source excerpt

People following me have occasionally seen me post graphs like this: image1400x391 74.2 KB Usually people leave this type of instrumentation and graphing to NewRelic and Skylight. However, at our scale we find it extremely beneficial to have instrumentation, graphing and monitoring local cause we are in the business of hosting, this is a central part of our job. Over the past few years Prometheus has emerged as one of the leading options for gathering metrics and alerting. However, sadly, people using Rails have had a very hard time extracting metrics. Issue #9 on the official prometheus client for Ruby has been open 3 years now, and there is very little chance it will be "solved" any time soon. The underlying fundamental issue is that Prometheus, unlike Graphite/Statsd is centered around the concept of pulling metrics as opposed to pushing metrics. This means you must provide a single HTTP endpoint that collects all the metrics you want exposed. This ends up being particularly complicated with Unicorn/Puma and Passenger who usually will run multiple forks of a process. If you simply implement a secured /metrics endpoint in your app, you have no guarantees over which forked process will handle the request, without "cross fork" aggregation you would just report metrics for a single, random, process. Which is less than useful. Additionally, knowing what to collect and how to collect it is a bit of an art, it can easily take multiple weeks just to figure out what you want. Having solved this big problem for Discourse I spent some time extracting the patterns. Introducing prometheus_exporter The prometheus_exporter gem is a toolkit that provides all the facilities you need. It has an extensible collector that allows you to run a single process to aggregate metrics for multiple processes on one machine. It implements gauge, counter and summary metrics. It has default instrumentation that you can easily add to your app It has a very efficient and robust transport channel