-
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
Vsphere nil pointers access in Metricbeat module #9784
Conversation
jenkins, test this |
Fail seems unrelated. Awaiting for review |
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.
Code LGTM, thanks for the quick fix. Left two minor comments about logging.
I also added the needs_backport
label as I think we should backport this to 6.5, 6.6, 6.x.
CI failure is not related.
1aebe7d
to
4dfefcd
Compare
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.
Left a few minor comments. Mostly nit picks to make the code nicer. Let me know what you think.
}, | ||
} | ||
|
||
if hs.Summary.Hardware != nil { | ||
totalCPU := int64(hs.Summary.Hardware.CpuMhz) * int64(hs.Summary.Hardware.NumCpuCores) | ||
cpu["total"] = common.MapStr{ |
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.
What you can use as an alternative here is cpu.Put('total.mhz', totalCPU)
. It will have the same effect. Using this you could still generate the full event as you had previously on line 118 and then use:
event.Put('cpu.total.mhz', totalCPU)
The outcome of the code is exactly the same but it would make it shorter and hopefully more readable.
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.
Entries have been updated. I quick look will give me some calm brain cycles 😄
1808197
to
72dbb2d
Compare
…elastic#9784) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…elastic#9784) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…elastic#9784) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…#9784) (#9822) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…#9784) (#9823) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…#9784) (#9824) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit 7c31ced)
…elastic#9784) (elastic#9824) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit a05b14e)
…elastic#9784) (elastic#9823) In Vsphere module, some fields returned by the Vsphere library contain pointers to some values that could potentially be nil. With this PR, we do a nil-check prior every access to any of those fields to avoid their writing in case they are nil and protecting Metricbeat from panicking. (cherry picked from commit a05b14e)
It seems that some fields within the vsphere module on Metricbeat are pointers where the
nil
check access is not being done. This can cause panics that are not easy to reproduce.This PR checks every pointer that acces a pointer from the
gvmomi
library which is used to access vsphere data.Initially, we only know about panics in the
virtualmachine
metricset but I have seen that thehost
metricset could potentially have the same problem