21 releases

0.8.5 Aug 23, 2022
0.8.4 Jan 19, 2022
0.8.3 Oct 18, 2021
0.8.2 Apr 26, 2021
0.3.0 Mar 14, 2019

#119 in HTTP server

Download history 2008/week @ 2023-12-13 980/week @ 2023-12-20 1019/week @ 2023-12-27 1447/week @ 2024-01-03 1970/week @ 2024-01-10 2279/week @ 2024-01-17 2413/week @ 2024-01-24 2381/week @ 2024-01-31 2640/week @ 2024-02-07 2479/week @ 2024-02-14 2414/week @ 2024-02-21 2669/week @ 2024-02-28 2207/week @ 2024-03-06 2240/week @ 2024-03-13 1991/week @ 2024-03-20 1964/week @ 2024-03-27

8,950 downloads per month
Used in 15 crates

MIT license

319 lines


Build Status crates.io docs.rs

Helper libary to export prometheus metrics using tiny-http. It's intended to help writing prometheus exporters without the need to setup and maintain a http webserver. If the program also uses a http server for other purposes this package is probably not the best way and rust-prometheus should be used directly.

It uses rust-prometheus for collecting and rendering the prometheus metrics and tiny-http for exposing the metrics through http.

NOTICE: You have to use the same prometheus crate version that is used by this crate. This crate currently uses the metrics stored in the global registry. A different prometheus crate will register to a different global registry. This means that the macros used to register new metrics do not expose metrics to this exporter.

This crate re-exports the prometheus crate to make it easier to keep versions in sync (see examples). Currently this crate uses prometheus version 0.13.

For information on how to migrate from an older crate version follow MIGRATION.

NOTICE Version 0.8.0 used a vulnerable version of tiny_http please update to version 0.8.1 or higher. See issue #18 for more information.


Add this to your Cargo.toml:

prometheus_exporter = "0.8"

The most basic way to use this crate is to run the following:

"failed to parse binding",
.expect("failed to start prometheus exporter");

This will start the exporter and bind the http server to After that you can just update the metrics how you see fit. As long as those metrics are put into the global prometheus registry the changed metrics will be exported.

Another way to use the crate is like this:

let exporter = prometheus_exporter::start("".parse().expect(
"failed to parse binding",
.expect("failed to start prometheus exporter");

let guard = exporter.wait_request()

This will block the current thread until a request has been received on the http server. It also returns a guard which will make the http server wait until the guard is dropped. This is useful to always export consistent metrics as all of the metrics can be updated before they get exported.

See the documentation and the examples for more information on how to use this crate.

Basic Example

You will need the following in your Cargo.toml

prometheus_exporter = "0.8"
env_logger = "0.9"
log = "0.4"
reqwest = { version = "0.11",features = ["blocking"] }

A very simple example looks like this (from examples/simple.rs):

// Will create an exporter with a single metric that does not change

use env_logger::{
use log::info;
use prometheus_exporter::prometheus::register_gauge;
use std::net::SocketAddr;

fn main() {
    // Setup logger with default level info so we can see the messages from
    // prometheus_exporter.

    // Parse address used to bind exporter to.
    let addr_raw = "";
    let addr: SocketAddr = addr_raw.parse().expect("can not parse listen addr");

    // Create metric
    let metric = register_gauge!("simple_the_answer", "to everything")
        .expect("can not create gauge simple_the_answer");


    // Start exporter
    prometheus_exporter::start(addr).expect("can not start exporter");

    // Get metrics from exporter
    let body = reqwest::blocking::get(&format!("http://{}/metrics", addr_raw))
        .expect("can not get metrics from exporter")
        .expect("can not body text from request");

    info!("Exporter metrics:\n{}", body);


~123K SLoC