Personal tools
Skip to content. | Skip to navigation
The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus. The Pushgateway is explicitly not an aggregator, but rather a metrics cache. It does not have a statsd-like semantics. The metrics pushed are exactly the same as you would present for scraping in a permanently running program. For machine-level metrics, the textfile collector of the Node exporter is usually more appropriate. The Pushgateway is best used for service-level metrics.
Prometheus exporter for RabbitMQ metrics.
Prometheus Exporter for Redis Metrics. Supports Redis 2.x, 3.x, 4.x, 5.x and 6.x
See https://github.com/prometheus/snmp_exporter/blob/master/README.md for documentation.
This is an exporter that exposes information gathered from SNMP for use by the Prometheus monitoring system. There are two components. An exporter that does the actual scraping, and a generator (which depends on NetSNMP) that creates the configuration for use by the exporter.
Prometheus Exporter Squid
statsd_exporter receives StatsD-style metrics and exports them as Prometheus metrics. Overview With StatsD To pipe metrics from an existing StatsD environment into Prometheus, configure StatsD's repeater backend to repeat all received metrics to a statsd_exporter process. This exporter translates StatsD metrics to Prometheus metrics via configured mapping rules. +----------+ +-------------------+ +--------------+ | StatsD |---(UDP/TCP repeater)--->| statsd_exporter |<---(scrape /metrics)---| Prometheus | +----------+ +-------------------+ +--------------+ Without StatsD Since the StatsD exporter uses the same line protocol as StatsD itself, you can also configure your applications to send StatsD metrics directly to the exporter. In that case, you don't need to run a StatsD server anymore. We recommend this only as an intermediate solution and recommend switching to native Prometheus instrumentation in the long term. Tagging Extensions The exporter supports Librato, InfluxDB, and DogStatsD-style tags, which will be converted into Prometheus labels. For Librato-style tags, they must be appended to the metric name with a delimiting #, as so: metric.name#tagName=val,tag2Name=val2:0|c See the statsd-librato-backend README for a more complete description. For InfluxDB-style tags, they must be appended to the metric name with a delimiting comma, as so: metric.name,tagName=val,tag2Name=val2:0|c See this InfluxDB blog post for a larger overview. For DogStatsD-style tags, they're appended as a |# delimited section at the end of the metric, as so: metric.name:0|c|#tagName=val,tag2Name=val2 See Tags in the DogStatsD documentation for the concept description and Datagram Format. If you encounter problems, note that this tagging style is incompatible with the original statsd implementation. Be aware: If you mix tag styles (e.g., Librato/InfluxDB with DogStatsD), the exporter will consider this an error and the sample will be discarded. Also, tags without values (#some_tag) are not supported and will be ignored.
Django middlewares to monitor your application with Prometheus.io. Python 3 version.
ironic-prometheus-exporter provides a way to export hardware sensor data from ironic project in OpenStack to Prometheus. It's implemented as an oslo-messaging notification driver to get the sensor data and a Flask Application to export the metrics to Prometheus. It can be used not only in metal3 but in any OpenStack deployment which includes Ironic service.