Make descriptions static where they are not #3201
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since the description of the Meters can be different per Meter, we can run into weird situations when the description is dynamic/different for different Meter.Ids that share the same name but differ in tags for backends that does not support different description per time series.
jvm.threads.states:
The description here (Prometheus group) is "The current number of threads having NEW state".
This is somewhat misleading since we have time series for all of the states not just "NEW".
# HELP jvm_threads_states_threads The current number of threads having NEW state
# TYPE jvm_threads_states_threads gauge
jvm_threads_states_threads{state="new",} 0.0
jvm_threads_states_threads{state="timed-waiting",} 3.0
jvm_threads_states_threads{state="blocked",} 0.0
jvm_threads_states_threads{state="waiting",} 12.0
jvm_threads_states_threads{state="terminated",} 0.0
jvm_threads_states_threads{state="runnable",} 7.0
logback.events:
The description here (Prometheus group) is "Number of error level events that made it to the logs".
This is somewhat misleading since we have time series for all of the levels not just "error".
# HELP logback_events_total Number of error level events that made it to the logs
# TYPE logback_events_total counter
logback_events_total{level="info",} 6.0
logback_events_total{level="debug",} 0.0
logback_events_total{level="warn",} 0.0
logback_events_total{level="error",} 0.0
logback_events_total{level="trace",} 0.0
jack-berg
approved these changes
May 26, 2022
shakuzen
added
module: micrometer-core
|
Hi jonatan, I found there are a log of similar cases here, such as |
|
@julian-zhu96 I can go through the cache-related binders, I see the ones you mentioned, do you happen to have a list about them? |
|
@julian-zhu96 see #3321 |
|
@jonatan-ivanov No, I don't have a list. But I found this to be the case for almost half of the meters, because I lost almost half of the microservice metrics data when collected by opentelemetry collector and sent to prometheus |
|
Check with the latest snapshot, theoretically I fixed it for cache metrics. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the
descriptionof theMeters can be different perMeter, we can run into weird situations when the description is dynamic/different for differentMeter.Ids that share the same name but differ in tags for backends that does not support different description per time series.jvm.threads.states
The description here (Prometheus group) is
The current number of threads having NEW state.This is somewhat misleading since we have time series for all of the states not just
NEW.logback.events
The description here (Prometheus group) is
Number of error level events that made it to the logs.This is somewhat misleading since we have time series for all of the levels not just
error.