-
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
Fixes parsing of GC entries in elasticsearch server log #9603
Conversation
Pinging @elastic/stack-monitoring |
@ycombinator Could you rebase on master. The failing CI should be fixed there. |
@ruflin Rebased on |
@radoondas has suggested a few improvements so I'm taking this PR out of |
Thanks to @radoondas's work, the ingest pipeline in this PR now includes a script processor to parse the GC durations into meaningful numeric millisecond values. It also further breaks down the grok expressions to make them even more readable. |
@ycombinator you've described the metrics as |
Thanks @tsouza. Fixing both those things... [UPDATE] Leaving the sequence number as-is per our conversation off-PR. |
I've incorporated the latest feedback into this PR. It is ready for review again. Thanks! |
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 looks now good to go. It does not break BC and build fields for future use.
Base of the changes - breaking the pattern - will help to build new special requests from user base.
{ | ||
"script": { | ||
"lang": "painless", | ||
"source": "if (ctx.elasticsearch.server.gc != null && ctx.elasticsearch.server.gc.observation_duration != null) { if (ctx.elasticsearch.server.gc.observation_duration.unit == 's') { ctx.elasticsearch.server.gc.observation_duration.time_in_millis = ctx.elasticsearch.server.gc.observation_duration.time * 1000;}if (ctx.elasticsearch.server.gc.observation_duration.unit == 'ms') { ctx.elasticsearch.server.gc.observation_duration.time_in_millis = ctx.elasticsearch.server.gc.observation_duration.time; } if (ctx.elasticsearch.server.gc.observation_duration.unit == 'm') { ctx.elasticsearch.server.gc.observation_duration.time_in_millis = ctx.elasticsearch.server.gc.observation_duration.time * 60000; }} if (ctx.elasticsearch.server.gc != null && ctx.elasticsearch.server.gc.collection_duration != null) { if (ctx.elasticsearch.server.gc.collection_duration.unit == 's') { ctx.elasticsearch.server.gc.collection_duration.time_in_millis = ctx.elasticsearch.server.gc.collection_duration.time * 1000;} if (ctx.elasticsearch.server.gc.collection_duration.unit == 'ms') {ctx.elasticsearch.server.gc.collection_duration.time_in_millis = ctx.elasticsearch.server.gc.collection_duration.time; } if (ctx.elasticsearch.server.gc.collection_duration.unit == 'm') { ctx.elasticsearch.server.gc.collection_duration.time_in_millis = ctx.elasticsearch.server.gc.collection_duration.time * 60000; }}" |
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.
@jpountz Great use case for a duration type (mostly) ;-)
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.
:)
@ycombinator I wonder if an improvement can be made later on on the ES side to always log in the same unit? |
@ruflin Added I've also spoken with @jakelandis about the possibility of adding a |
@jsoriano Thanks for your review. I've addressed all your feedback now. Ready for your 👀 again! Additionally I've also shortened the painless expression a bit by using the null-safe operator. |
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.
Thanks everyone for fixing this!
LGTM
jenkins, test this |
…ore readable Co-authored-by: Radovan Ondas <[email protected]>
…h server log (#9810) * Regenerating fields * Fixing up for 6.x * Adding CHANGELOG entries
Resolves #9513.
This PR:
gc_overhead
field. Turns out what we were parsing was actually an insignificant sequential number, not GC overhead,gc.collection_duration
field, e.g.1.2s
, which is the time spent performing GC, andgc.observation_duration
field, e.g.1.8s
, which is the overall time over which GC collection was performedIt also splits up the long grok expression in the ingest pipeline into smaller patterns and references those patterns, hopefully for easier readability.