-
Notifications
You must be signed in to change notification settings - Fork 55
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
Added -R
to check-process.rb for RSS checks
#46
Changes from 4 commits
13f4dd8
70d2fd8
c75579d
8e555a6
bca53db
fd34458
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -117,9 +117,17 @@ class CheckProcess < Sensu::Plugin::Check::CLI | |
description: 'Trigger on a Virtual Memory size is bigger than this', | ||
proc: proc(&:to_i) | ||
|
||
# Alert if RSS is under this value | ||
option :rss, | ||
short: '-r RSS', | ||
long: '--resident-set-size RSS', | ||
description: 'Trigger on a Resident Set size is smaller than this', | ||
proc: proc(&:to_i) | ||
|
||
# Alert if RSS is over this value | ||
option :over_rss, | ||
short: '-R RSS', | ||
long: '--over-resident-set-size RSS', | ||
description: 'Trigger on a Resident Set size is bigger than this', | ||
proc: proc(&:to_i) | ||
|
||
|
@@ -209,7 +217,7 @@ def line_to_hash(line, *cols) | |
# | ||
def on_cygwin? | ||
# #YELLOW | ||
`ps -W 2>&1`; $CHILD_STATUS.exitstatus == 0 # rubocop:disable Semicolon | ||
`ps -W 2>&1`; $CHILD_STATUS.exitstatus.zero? # rubocop:disable Semicolon | ||
end | ||
|
||
# Acquire all the proceeses on a system for further analysis | ||
|
@@ -249,6 +257,7 @@ def cputime_to_csec(time) | |
|
||
# The main function | ||
# | ||
# rubocop:disable Metrics/AbcSize | ||
def run | ||
procs = acquire_procs | ||
|
||
|
@@ -261,7 +270,10 @@ def run | |
procs.reject! { |p| p[:command] =~ /#{config[:exclude_pat]}/ } if config[:exclude_pat] | ||
procs.reject! { |p| p[:command] !~ /#{config[:cmd_pat]}/ } if config[:cmd_pat] | ||
procs.select! { |p| p[:vsz].to_f > config[:vsz] } if config[:vsz] | ||
# Ensure RSS is over this value | ||
procs.select! { |p| p[:rss].to_f > config[:rss] } if config[:rss] | ||
# Ensure RSS is under this value | ||
procs.select! { |p| p[:over_rss].to_f < config[:over_rss] } if config[:over_rss] | ||
procs.select! { |p| p[:cpu].to_f > config[:cpu_utilization] } if config[:cpu_utilization] | ||
procs.select! { |p| p[:thcount].to_i > config[:thcount] } if config[:thcount] | ||
procs.reject! { |p| etime_to_esec(p[:etime]) >= config[:esec_under] } if config[:esec_under] | ||
|
@@ -277,6 +289,7 @@ def run | |
msg += "; user #{config[:user].join(',')}" if config[:user] | ||
msg += "; vsz > #{config[:vsz]}" if config[:vsz] | ||
msg += "; rss > #{config[:rss]}" if config[:rss] | ||
msg += "; rss < #{config[:over_rss]}" if config[:over_rss] | ||
msg += "; cpu > #{config[:cpu_utilization]}" if config[:cpu_utilization] | ||
msg += "; thcount > #{config[:thcount]}" if config[:thcount] | ||
msg += "; esec < #{config[:esec_under]}" if config[:esec_under] | ||
|
@@ -287,7 +300,7 @@ def run | |
|
||
if config[:metric] | ||
# #YELLOW | ||
count = procs.map { |p| p[config[:metric]].to_i }.reduce { |a, b| a + b } # rubocop:disable SingleLineBlockParams | ||
count = procs.map { |p| p[config[:metric]].to_i }.reduce { |a, e| a + e } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand this change or why it would fix rubocop you just renamed the variables...can you expand? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comes from Style/SingleLineBlockParams. Here are the tests rubocop runs for an example of what led to the message:
I'm perfectly happy to put things back how I found them, but I guessed that a previous committer may not have fully understood the SingleLineBlockParams cop and could have avoided the Might have had something to do with my editor vs. running rubocop from the CLI, but I ran Let me know how to proceed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see a real change so unless someone can explain why one is good and the other is bad I am going to assume that this is a false positive, highly subjective / opinionated, or just a bad rule. I would prefer to ignore behavior rather than make a change without a reason. Would you be open to creating an issue on rubocop and feel free to tag me on this? If there is something that makes this special I would like to know. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll undo this change in a commit in just a second. For your reference, the docs for rubocop for this rule are here: http://rubocop.readthedocs.io/en/latest/cops_style/#stylesinglelineblockparams The relevant section is I'm guessing Either way, not trying to impose more rules than this repo's maintainers would care to adhere to, so I'll revert this change. |
||
msg += "; #{config[:metric]} == #{count}" | ||
else | ||
count = procs.size | ||
|
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 comment is wrong...swap it with the comment above.
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 can clarify (or remove entirely) the comments I added there, but I'm not sure they are incorrect. Looking at both RSS-related selects:
The first (and original) selects only those processes (
p
) whose reported RSS (:rss
) is greater than the supplied value inconfig
(thus my comment of# Ensure RSS is over this value
).The second selects only those processes whose reported RSS is less than the supplied value in the
config
(thus my comment of# Ensure RSS is under this value
). Albeit, the use of "under" and the config key of:over_rss
is not super clear, my intention on the new-R
is to alert when the RSS value goes over the value you specify on the command line, so I think it still fits.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.
That said, my last comment made me see that the process (
p
) key should be:rss
for that comparison. You'll see another commit in just a second.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.
that must have been what threw me off, makes perfect sense 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.
This still looks wrong to me:
I would write it like this which makes more sense to me:
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 am wondering if we should just always log a message saying something to this effect:
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.
Actually I am almost tempted to say there should be no defaults for any of the crit/warnings if we want to stay flexible and keep it all in the same check. Let the user tell us what they want to check as we cant have sane defaults for both scenarios as they are mutually exclusive from what I see.
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 would obviously be a breaking change @eheydrick thoughts?
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 thankful that I'm not the only one that finds this check's options less than intuitive. I'm happy with postponing / canceling this PR until this discussion is concluded. I'll probably just write a really simple check to do just what I need for now. I'm also happy to help contribute to a library too if that would be valuable.
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 can do what you need with the existing features as outlined above. you just need to set
-w, -c
to what they should be. Let's close out this PR and continue the discussion in the issue. I really do want to improve this but what is proposed is already available so unless we make things more intuitive I don't see anything that should be addressed here.