Add the service.name label to all metrics
#116
Conversation
| @@ -112,6 +112,10 @@ fn instrument_function(args: &AutometricsArgs, item: ItemFn) -> Result<TokenStre | |||
| quote! { None } | |||
| }; | |||
|
|
|||
| let service_name = quote! { | |||
| autometrics::__private::service_name(env!("CARGO_PKG_NAME")) | |||
There was a problem hiding this comment.
If my service name is set via a config file / flag instead of an environment variable, is there a plan for supporting that?
There was a problem hiding this comment.
Good question. There is a way we could support that, I'm just not sure if we should do it now. I started a separate issue to discuss this #117
| @@ -112,6 +112,10 @@ fn instrument_function(args: &AutometricsArgs, item: ItemFn) -> Result<TokenStre | |||
| quote! { None } | |||
| }; | |||
|
|
|||
| let service_name = quote! { | |||
| autometrics::__private::service_name(env!("CARGO_PKG_NAME")) | |||
There was a problem hiding this comment.
If I have multiple engineers with instanced environments, should the instanced service names be handled via this, or is there a better place for that? E.g. if I have a loadbalancer service and I have an instanced environment for a PR where I update said loadbalancer, should this be set to the branch name::service of akesling-update-loadbalancer::loadbalancer or something similar?
There was a problem hiding this comment.
This is setting the service.name either based on runtime environment variables (AUTOMETRICS_SERVICE_NAME or OTEL_SERVICE_NAME) or it will fall back to the package name defined in the Cargo.toml. I think in the case of a load balancer you would just use the runtime environment variables to set it to whatever makes sense for your deployment configuration.
|
I'm going to merge this now but we can still add the initialization function in another PR |
Currently, this only supports loading the
service.namefrom environment variables.For the moment, I opted not to allow setting the
service.namelabel by passing a parameter to theautometricsmacro. It seems like a footgun to allow you to set different values for different metrics in the same service.It might be nice to have a way to set the
service.nameusing some initialization function, but we don't have a global initialization function yet for the Rust implementation. We could add it just for this purpose, but it seems like we could also wait until someone comes with a request along these lines. Also, it might be slightly confusing to have separateinitfunctions forautometricsas well asautometrics::prometheus_exporter.I'm curious what others think. cc @akesling