-
Notifications
You must be signed in to change notification settings - Fork 28
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
(SLV-771) Fix bug where process data is missed #42
Conversation
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.
You may want to review your commit comment. It could use a little bit of love.
LTGM, though this comment is explicit and subject to being out of sync:
FWIW, these
as they are inherent:
https://ruby-doc.org/stdlib-2.4.1/libdoc/fileutils/rdoc/FileUtils.html#method-c-mkdir_p |
These files could/should be functionaly identical: puppetlabs-puppet-metrics-viewer/json2graphite.rb puppetlabs-puppet_metrics_collector/files/json2timeseriesdb With this commit: Bi-directional merge of changes. Added comments. Replaced unnessary double-quotes with single-quotes.
The process data gathering greps process names for the ones we wanted to track... then passes the list to sar to track. If a process passed to sar exists when sar starts, but exits before sar gathers the first round of data, then sar will crash while printing the average summaries. Thus we lose data. Also, if the process exited before sar ran, there would be no data and some of the generate_system_metrics code would crash expecting to find that process in the sar results. Fine tuned the process grep to avoid matching processes we don't care about. Put a catch to not crash if one of the processes we expect doesn't have any data.
@tkishel @johnduarte Fixed commit and PR message. made the example more general. |
If we are all good, let's merge this. |
The process data gathering greps process names for the ones we wanted to track... then passes the list to sar to track. If a process passed to sar exists when sar starts, but exits before sar gathers the first round of data, then sar will crash while printing the average summaries. Thus we lose data.
Also, if the process exited before sar ran, there would be no data and some of the generate_system_metrics code would crash expecting to find that process in the sar results.
Fine tuned the process grep to avoid matching processes we don't care about.
Put a catch to not crash if one of the processes we expect doesn't have any data.