Skip to content
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

Merged
merged 4 commits into from
Oct 4, 2017

Conversation

rthouvenin
Copy link
Contributor

@rthouvenin rthouvenin commented Sep 18, 2017

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

Copy link
Member

@majormoses majormoses left a 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

'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']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should freeze constants.

Copy link
Contributor Author

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?

Copy link
Member

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.

@@ -208,6 +227,12 @@ def main():
dest = 'graphite_scheme',
metavar = 'GRAPHITE_SCHEME')

parser.add_option('-m', '--metrics',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@rthouvenin rthouvenin Sep 25, 2017

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')?

Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor Author

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 ,.

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright!

@@ -89,6 +90,21 @@
'CLOSING',
'NONE'
]
HANDLER_STATS = {
Copy link
Member

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.

Copy link
Contributor Author

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 ifs 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 ifs.

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@rthouvenin
Copy link
Contributor Author

Here is a gist with the output of a few test runs at this stage: https://gist.github.com/rthouvenin/f43ab687b85c7543b781668a3ac7b8a2

Copy link
Member

@majormoses majormoses left a 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?

@@ -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):
Copy link
Member

@majormoses majormoses Sep 30, 2017

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.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Member

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.

@majormoses majormoses merged commit fb21c75 into sensu-plugins:master Oct 4, 2017
@majormoses
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants