-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Ability to customize the default ObservationEnvironmentRepositoryObservationConvention #2383
Comments
Thanks for opening the issue @sergioasantiago. I am curious on how you tried to add the |
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
Hi 🧇 I apologize for the delay. I ended up circumventing this by creating a GlobalObservationConvetion that will overwrite the one used by config-server.
|
It should, I think this might be a bug that should be fixed. If you look into the instrumentation: Lines 64 to 66 in 7adbc3f
The first parameter of the Observation observation(@Nullable ObservationConvention<T> customConvention, ObservationConvention<T> defaultConvention, ...) We should figure out how to let the users inject a
I think I still agree with the instrumentation. The application still seems to be a low cardinality tag even if you have lots of them. Having a lot does not necessarily mean high cardinality, see this: https://develotters.com/posts/high-cardinality/ You can do 3 things to mitigate this issue right now (4 after we add customization for the convention):
|
Is your feature request related to a problem? Please describe.
Current implementation doesn't allow to customize the default ObservationEnvironmentRepositoryObservationConvention implementation. The default implementation adds to the lowCardinalityTags the application. This can be a problem when we have many applications, like our use case. This is exploding the cardinality for this metric when we expose this metric to prometheus and this is a known performance issue.
Describe the solution you'd like
I would like to be able to change the tags that are exported in metrics.
Describe alternatives you've considered
I tried to use an ObservationFilter as described in micrometer docs, but since it is a post-processing component it didn't take effect.
The text was updated successfully, but these errors were encountered: