-
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
Add filter for stats name #52
Add filter for stats name #52
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.
Overall it looks ok ither than being unnecessarily complex. I would prefer if we followed other established patterns like the one in redis: https://github.com/sensu-plugins/sensu-plugins-redis/blob/2.2.1/bin/metrics-redis-graphite.rb I am not saying I am 100% forcing you to change but but I am certainly encouraging a more simple (which are typically less error prone). Also I need a testing artifact per: https://github.com/sensu-plugins/community/blob/master/PULL_REQUEST_PROCESS.md#7-testing-artifacts
bin/metrics-per-process.py
Outdated
'io_counters.read_bytes': lambda ctx: ctx.io_counters().read_bytes, | ||
'io_counters.write_bytes': lambda ctx: ctx.io_counters().write_bytes, | ||
} | ||
MEMORY_STATS = ['rss', 'vms', 'shared', 'text', 'lib', 'data', 'dirty'] |
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 should freeze constants.
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 mean use a tuple instead of a list?
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.
disregard I was clearly too tired when I reviewed this.
bin/metrics-per-process.py
Outdated
@@ -208,6 +227,12 @@ def main(): | |||
dest = 'graphite_scheme', | |||
metavar = 'GRAPHITE_SCHEME') | |||
|
|||
parser.add_option('-m', '--metrics', |
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 think that a name like this: https://github.com/sensu-plugins/sensu-plugins-redis/blob/2.2.1/bin/metrics-redis-graphite.rb#L94-L98 would be better
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.
Sure. add_option('-k', '--filter-keys', ..., 'keys', 'KEYS_REGEXP')
?
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.
Is this an inclusive or exclusive filter? If inclusive I think --keys-regex
otherwise --skip-keys-regex
but I do not feel super strongly about it. @eheydrick ping
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 or --metrics-regex
given that metrics is the thing being collected and more specific.
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'd be 👍 with --metric-regexes
to make it obvious that we are not requiring a single regex but a list of regexes to be used.
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 it's actually a single regex, isn't it? Or do we want to have a comma-separated list of regexes to make it easier for the user to write the regex? IMO, separating keys with a |
in a single regex isn't more difficult or very different from several regexes separated with a ,
.
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 is true when you have very simple regexes but the more complex the more it is a pain to look at. I'd prefer a comma separated list of regexes as this follows established patterns in both graphite and redis plugins. If we think that is overkill I am ok with limiting the scope but prefer consistency where possible.
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.
Alright!
bin/metrics-per-process.py
Outdated
@@ -89,6 +90,21 @@ | |||
'CLOSING', | |||
'NONE' | |||
] | |||
HANDLER_STATS = { |
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.
seems like there is a much simpler way to do this, if it matches the regex just call it in the loop (no need for a lambda) otherwise just move on. It's not that I am opposed to using lambda's when it makes sense this just seems overly complex without any real benefit over something more straightforward.
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 also wasn't sure about which way to go. Without lambdas would be simpler, but it would replace the loop with a large collection of if
s like:
if metrics_regexp.match('cpu.user'):
stats['cpu.user'] = process_handler.cpu_times().user
It's not as DRY as the lambdas because the stat name is repeated, as well as the "pattern" of checking the match and storing in the dictionary. If the loss in simplicity is not worth the gain, I have no problem going for the collection of if
s.
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 tend to write really good python in my ruby so I have never really been opposed to a bunch of if statements, much easier to follow and less rubyisms (not that lambdas are really a rubyism) are I think desired in plugins where possible. Ideally with plugins I try to write it in the most simplest of forms. This means that traditional nocs, sysadmins, etc that do not really want to learn a ton of coding can still follow and fix bugs but that might just be me. At my work I take a similar stance for a very different reason, if I need to think about it at 3 AM (when I care the most about fixing an issue quickly so I can go back to bed) when I was just pulled out of bed does it make sense, if not it either needs some healthy comments explaining what is going on or it needs to be re-written.
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.
+1 for comments on "tricky" looking code.
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.
Makes total sense, I'll go for the if
statements.
Here is a gist with the output of a few test runs at this stage: https://gist.github.com/rthouvenin/f43ab687b85c7543b781668a3ac7b8a2 |
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.
One minor tweak on naming but otherwise I think it looks good. @eheydrick you want to take another pass at it?
bin/metrics-per-process.py
Outdated
@@ -107,60 +109,115 @@ def find_pids_from_name(process_name): | |||
pass | |||
return pids | |||
|
|||
def stats_per_pid(pid): | |||
'''Gets process stats using psutil module | |||
def other_stats(process_handler, metrics_regexp): |
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 think maybe something likeadditional_stats
is more descriptive.
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.
Done, let me know if I should squash all the commits
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.
Nah, its good github now has an easy squash + merge button.
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.
and honestly the history is not bad here.
Pull Request Checklist
Implements #43. Adds a command line option to
metrics-per-process.py
to filter with a regexp the stats to output. Prints everything by default for backward compatibility. The stats that are filtered out are not queried, which avoids getting permission errors for stats that are not required.General
Update Changelog following the conventions laid out on Keep A Changelog
Update README with any necessary configuration snippets
N/A Binstubs are created if needed
N/A RuboCop passes
N/A Existing tests pass