Hi Dave,
As mentioned on IRC, pmie doesn't appear to use local: connection
by default - looks like a hostname is associated with each metric
at some point, and that is used when it comes to the crunch of
fetching values for a metric (instead of the local: context which
we do also establish earlier on in argument parsing, it seems).
There's a pmie config in the IRC log below that shows the problem
using the proc metrics (which give permission errors when no auth
info available). A gdb breakpoint on pmNewContext shows where we
start wandering off the expected path. So, removing :'local:' in
that config (explicit host) shows the problem - as-is, the config
below *does* do an af_unix connection because of that workaround.
cheers.
<chandana_> i want to count the number of httpd processes in pmie
<chandana_> so I thought of something like this
<chandana_> (count_inst > 5 && match_inst "httpd")
<nathans> ah, and using the proc.* metrics?
<chandana_> not sure if I am using count_inst corerctly
<chandana_> yes
<nathans> yeah, i'd be surprised if count_inst does what you want there
<nathans> hmmm
<nathans> (thinking, thinking)
<nathans> so far, the only way i can think of doing (using stock pcp code) it
is via a pmie rule with match_inst, then using %i in the rule evaluation, then
counting the passed-in arguments in the action (shell script)
<nathans> a couple of more involved approaches would be to use the cgroups
support in current pmdaproc, if you can ensure all httpd processes start in a
named cgroup
<nathans> or, resurrecting pmdahotproc (src/pmdas/hotproc)
<chandana_> (match_inst "httpd" proc.cmd )
<chandana_> -> print "httpd procs %i";
<chandana_> tried that, syntax error - near line 11 of file status.pmie
<chandana_> logical expression expected to follow regular expression
<chandana_> can you show me an example of count_inst ?
<nathans> yeah, thats not a valid pmie expression
<chandana_> I realise that
<nathans> see the man page example, i.e. match_inst "^dks[23]d" disk.dev.total
> 20;
<chandana_> yes.
<chandana_> just that proc.psinfo.cmd is text
<nathans> something like this might work...
<nathans> match_inst "bash" proc.psinfo.pid > 0;
<nathans> s/bash/httpd
<chandana_> mm, that gives and error in pmie, but works on pminfo
<chandana_> Instance domain for metric proc.psinfo.pid from host
hr1.dev.m4u.com.au not (currently) available
<chandana_> pmGetIndom failed: No permission to perform requested operation
<nathans> yeah, just looking into that atm
<nathans> ok, some progress ... hang on a tick
<chandana_> I think if I can use proc.psinfo.threads, I will get what I need
<nathans> ok, this works...
<nathans> cat /tmp/pmie
<nathans> some_inst ( match_inst ".*bash" proc.psinfo.pid :'local:' > 0 ) ->
print " '%i',pid=%v";
<nathans> pmie -c /tmp/pmie -t 1 -v -v -e
<nathans> Tue Feb 4 09:05:43 2014: '010766 bash',pid=10766 '011349
bash',pid=11349 '015594 -bash',pid=15594
<nathans> expr_1 (Tue Feb 4 09:05:43 2014): true
<nathans> Tue Feb 4 09:05:44 2014: '010766 bash',pid=10766 '011349
bash',pid=11349 '015594 -bash',pid=15594
<nathans> expr_1 (Tue Feb 4 09:05:44 2014): true
<chandana_> ah thanks
<nathans> np - the local: bit there resolves the permissions issue
<nathans> not really sure why thats not happening by default, i'll need to dig
into that
<chandana_> ok, that makes sense
<chandana_> that worked
<nathans> good stuff
--
Nathan
|