-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Log absolute values for gauges internal metrics #5505
Conversation
We currently don't have a way for the internal Beats metrics to register themselves as counters or gauges, so the logging code that prints the values every 30s assumes they are all counters and prints the difference since the last update. This issue has became more pressing in 6.0 because we now have several common gauges. This PR implements a temporary hack that lists these gauges in logging code. A follow up PR will create a proper solution for the next release. Part of elastic#5433.
"beat.memstats.memory_total": true, | ||
"beat.memstats.memory_alloc": true, | ||
"beat.memstats.gc_next": true, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one presents a problem because the name is not known ahead of time. Perhaps a pattern could be used to handle it or we just ignore it (I doubt anyone will be using this metric before we have a final solution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I saw that one. I'd say we just ignore it in this phase and it can be handled with the real solution.
We currently don't have a way for the internal Beats metrics to register themselves as counters or gauges, so the logging code that prints the values every 30s assumes they are all counters and prints the difference since the last update. This issue has became more pressing in 6.0 because we now have several common gauges. This PR implements a temporary hack that lists these gauges in logging code. A follow up PR will create a proper solution for the next release. Part of elastic#5433. (cherry picked from commit 6f8d5eb)
We currently don't have a way for the internal Beats metrics to register themselves as counters or gauges, so the logging code that prints the values every 30s assumes they are all counters and prints the difference since the last update. This issue has became more pressing in 6.0 because we now have several common gauges. This PR implements a temporary hack that lists these gauges in logging code. A follow up PR will create a proper solution for the next release. Part of #5433. (cherry picked from commit 6f8d5eb)
We currently don't have a way for the internal Beats metrics to register themselves as counters or gauges, so the logging code that prints the values every 30s assumes they are all counters and prints the difference since the last update. This issue has became more pressing in 6.0 because we now have several common gauges. This PR implements a temporary hack that lists these gauges in logging code. A follow up PR will create a proper solution for the next release. Part of elastic#5433.
We currently don't have a way for the internal Beats metrics to register
themselves as counters or gauges, so the logging code that prints the
values every 30s assumes they are all counters and prints the difference
since the last update.
This issue has became more pressing in 6.0 because we now have several
common gauges. This PR implements a temporary hack that lists these gauges
in logging code. A follow up PR will create a proper solution for the next
release.
Part of #5433.