-
Notifications
You must be signed in to change notification settings - Fork 29
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
Enable Objective
details to be loaded from environment variables
#115
Comments
Actually, this is going to be trickier than I thought. You can set up the use autometrics::{autometrics, objectives::*};
use once_cell::sync::Lazy;
use std::env;
static OBJECTIVE_NAME: Lazy<String> = Lazy::new(|| env::var("OBJECTIVE_NAME").unwrap_or("my-objective".to_string()));
static OBJECTIVE_PERCENTILE: Lazy<ObjectivePercentile> = Lazy::new(|| match env::var("OBJECTIVE_PERCENTILE").as_deref() {
Ok("P90") => ObjectivePercentile::P90,
Ok("P95") => ObjectivePercentile::P95,
Ok("P99") => ObjectivePercentile::P99,
Ok("P99_9") => ObjectivePercentile::P99_9,
_ => ObjectivePercentile::P95,
});
static OBJECTIVE: Lazy<Objective> = Lazy::new(|| Objective::new(&OBJECTIVE_NAME)
.success_rate(*OBJECTIVE_PERCENTILE));
#[autometrics(objective = OBJECTIVE)]
pub fn api_handler() {
// ...
} The problem is that the type that we're expecting is an I don't know if there's an easy way to get around this... |
This problem I described above is the same as described in matklad/once_cell#244 |
Would it be an option to extend |
Yeah I think something like that might be a good solution. We could even have a specific |
Please be mindful with those env variables. I've just filled an issue because the crate doesn't compile due to another host env variable that is inaccessible from a hermetic build. I don't know the best path forward fro this issue, but in all fairness some constants combined with the option type and custom constructors may yield a deterministic result regardless of env variables. |
A number of people have described use cases where the details of an SLO may be different for different instances of the same service. For example, a service that has specific instances for each geographical region, where each has its own SLO.
The main thing we would need to change in order to support this would be to make the
Objective
details useString
s instead of&'static str
s and the methods would need to be non-const
(this would be a breaking change). Then, you'd be able to define an objective like this:We could potentially add helper functions for loading the values from environment variables, or we could just show how to do this in the docs.
The text was updated successfully, but these errors were encountered: