-
Notifications
You must be signed in to change notification settings - Fork 8.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
[Monitoring] JVM memory usage alert #79039
Conversation
Pinging @elastic/stack-monitoring (Team:Monitoring) |
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.
Overall, looking good! I found a few things
nextSteps: [ | ||
createLink( | ||
i18n.translate('xpack.monitoring.alerts.memoryUsage.ui.nextSteps.tuneThreadPools', { | ||
defaultMessage: '#start_linkTune thread pools#end_link', |
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 don't see this listed in Ravi's doc. Was it a last minute addition?
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.
It wasn't on the list, but based on my research it is also a valuable resource to mitigate high memory usage. cc: @ravikesarwani wdyt?
if (ccs) { | ||
globalState.push(`ccs:${ccs}`); | ||
} | ||
globalState.push('refreshInterval:(pause:!f,value:10000),time:(from:now-1h,to:now)'); |
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.
Why add this?
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.
To keep it consistent with our defaults, otherwise it'll use timerange default of 15min, which will then persist to next state once they start navigating the app
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.
But our defaults are defined here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/monitoring/public/plugin.ts#L134?
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, but it won't transfer to url_state
unless we explicitly provide it (like I'm doing above). You can test this for yourself
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.
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.
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.
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.
It also relies on localStorage
. Maybe try clearing it, or at least the following key:
kibana.timepicker.timeHistory: "[{"from":"now-1h","to":"now"},{"from":"now-15m","to":"now"}]"
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 agree it isn't related to this PR and we should defer the conversation, but we should have it at some point. I'm curious if there is an actual bug around this code that we need to fix.
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.
Hey catching up on this, I think introducing more than one place to define defaults is probably not a good idea and we should understand why it's needed before we introduce that kind of foot-gun.
For now, if the goal is to get this alert in before FF, I recommend removing that line and then during the test plan phase try to understand why you both are seeing these different behaviors, and then document that back on this PR or in a new ticket. Hopefully it's not necessary at all, but if it is, we should export the defaults as a constant and then use it in both places at the very least.
x-pack/plugins/monitoring/server/lib/alerts/fetch_memory_usage_node_stats.ts
Show resolved
Hide resolved
x-pack/plugins/monitoring/server/lib/alerts/fetch_memory_usage_node_stats.ts
Show resolved
Hide resolved
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
async chunks size
distributable file count
page load bundle size
History
To update your PR or re-run it, just comment with: |
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.
LGTM!
* Memory usage first draft * Fixed tests * CR feedback * Feedback and tests * Added size to optimize query * Removed scheduled check * Removed globalstate date Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Kibana Machine <[email protected]>
Backport: |
Resolves #74824
This is part of the "Additional Alerting" effort for Stack Monitoring
The check calculates each data node to make sure the JVM memory usage is below the implied threshold.
Testing:
*Note: that it might take a couple of minutes for the notification to show up in the UI