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.
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
[Stack Monitoring] Update flows for cpu stats fetching #167244
[Stack Monitoring] Update flows for cpu stats fetching #167244
Changes from 6 commits
ff0e34a
35c4133
14c2544
6d3c9c5
cd96e17
e0a4e72
5ea419d
905a75d
fff5166
298cc59
dd746e0
16ed414
6c2bc8e
267192e
2615750
bfd4546
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm having real doubts about if we should log something or not.
On the one hand, this looks to me as a missed configuration but maybe it's more common than I think?
And then, having this logged every time the rule executes, possibly for many nodes, feels like a risk for spam which will make the Kibana log grow which means more cost of storing that log for no real gain and the customer might be fine with it.
So maybe we should make it a debug level instead? But, if we do, is it really useful? Will it help customers notice something is wrong.
I don't know if users really look at the Kibana logs anyway, similar for the log we make below about values missing?
Maybe both of those cases should just rely on the fallback metric silently?
I just feel like in the last PR, I included more changes than needed for the bug fix.
I think the limits change part is good because that's a real cause for bugs in the calculation.
But the other two cases should probably just silently return the base CPU metric since I'm not sure if either really helps the user find issues?
So my vote is to remove the logging here, and combine this check with the check below about if they are null, and not report any special status about that. What do you think?
That would bring the total set of changes closer to fixing only the original problem and removes a bunch of noise from the logs.
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.
Then after we check if the values are different or not.