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

Support deriving metric storage #120

Open
Ten0 opened this issue Dec 24, 2022 · 2 comments
Open

Support deriving metric storage #120

Ten0 opened this issue Dec 24, 2022 · 2 comments

Comments

@Ten0
Copy link

Ten0 commented Dec 24, 2022

It would be super useful to have derives for metrics storages, like was done for the prometheus crate (essentially porting https://crates.io/crates/prometheus-metric-storage).

#[derive(prometheus_metric_storage::MetricStorage)]
#[metric(subsystem = "transport", labels("endpoint"))]
struct Metrics {
    /// Number of requests that are currently inflight.
    inflight: prometheus::IntGauge,

    /// Number of finished requests by response code.
    #[metric(labels("status"))]
    requests_finished: prometheus::IntCounterVec,

    /// Number of finished requests by total processing duration.
    #[metric(buckets(0.1, 0.2, 0.5, 1, 2, 4, 8))]
    requests_duration_seconds: prometheus::Histogram,
}

fn main() {
    let metrics = Metrics::new(
        prometheus::default_registry(),
        /* endpoint = */ "0.0.0.0:8080"
    ).unwrap();

    metrics.inflight.inc();
    metrics.requests_finished.with_label_values(&["200"]).inc();
    metrics.requests_duration_seconds.observe(0.015);
}

This would enable to not forget to register metrics that are in a struct into the registry.

@mxinden
Copy link
Member

mxinden commented Jan 2, 2023

Do I understand correctly, that this would generate the metric registration logic? I am not opposed to adding this to this crate. That said, given that it would be a proc derive macro, I suggest doing so out-of-tree, potentially only for now.

@Ten0
Copy link
Author

Ten0 commented Jan 3, 2023

Do I understand correctly, that this would generate the metric registration logic?

Yes, currently it's pretty boilerplateish and error-prone when you have a significant set of metrics held in a struct that need to be registered, so that would make it really great on both aspects 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants