pcp
[Top] [All Lists]

Re: [pcp] [PATCH] PCP pidstat PMDA

To: myllynen@xxxxxxxxxx
Subject: Re: [pcp] [PATCH] PCP pidstat PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 20 Apr 2015 16:57:22 -0400 (EDT)
Cc: Martins Innus <minnus@xxxxxxxxxxx>, pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5534EBA8.4030509@xxxxxxxxxx>
References: <5534C680.2020709@xxxxxxxxxx> <493537984.3276058.1429528962326.JavaMail.zimbra@xxxxxxxxxx> <5534EBA8.4030509@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: PUNQI02ZyO/ueON26fI5LgJMoiVM2A==
Thread-topic: PCP pidstat PMDA
Hi Marko,

----- Original Message -----
> Hi,
> 
> On 2015-04-20 14:22, Nathan Scott wrote:
> >>
> >> please see below for a proposal for a new process level PMDA.
> >>
> >> There are other related PMDAs already (at least hotproc, linux_proc,
> >> and process) but I think this one complements the offering nicely
> >> with the ability to easily monitor certain processes (e.g., just say
> >> $procs = 'java' on the fly to start monitoring all java processes
> >> regardless of their PIDs) and also by providing e.g. per-process
> >> IO stats which are not easily (if at all) available from other PMDAs.
> > 
> > It sounds like there's alot of overlap here with hotproc.* - pmdaproc
> > nowadays provides hotproc.* metrics, thanks to Martins recent efforts,
> 
> hmm, which hotproc are we talking about? When looking at
> src/pmdas/hotproc, I don't see any notable recent changes, copyright
> dates are mostly from the previous millennium. Hmm, perhaps you are
> referring to linux_proc/hotproc.c which seems to have received updates
> recently?

Yes, the code is primarily in src/pmdas/linux_proc/hotproc.[ch] now.
(which reminds me, the old hotproc code should be dropped now, will do)

> > which may not be widely known yet (not really following the advantage
> > to parsing pidstat over accessing proc.* via hotproc ... am I missing
> > something subtle there?).
> 
> Btw, a general question, is there a way to access other metrics from
> PMDA? (Think of writing a PMDA which would provide custom metrics under
> "foo." but some special metrics would be calculated with help of some
> external metric like hinv or so.)

Yep, have a look at sample.secret.foo.bar.max.redirect in pmdas/sample.

> Ok, I wasn't aware of this, would be great to know how to do that, the
> above example doesn't seem to work and the pmdahotproc.1 man isn't
> really that helpful.

Yeah, docs need some love here I think.  Anyone able to volunteer?

> > Is there something missing from the hotproc.* metrics that this new
> > PMDA would provide Marko?  I don't really follow the IO-stats comment
> > - there's no magic that pidstat can do that pmdaproc cannot AFAIK in
> > terms of querying the kernel for stats.
> 
> The reason for using pidstat was mainly that it was quick to write the
> PMDA. As a bonus it also provided those read/s and write/s metrics which
> I didn't see readily available elsewhere.

I think those will be the values behind the proc.io.* metrics, FWIW, but
have not checked closely (see e.g. /proc/self/io).

> > From a quick look, the docs for the (recently-added-to-Linux) hotproc
> > metrics could be improved - Martins, could we find a way to report
> > help text for hotproc.control, hotproc.predicate, and hotproc.total?
> > And the pmdaproc(1) man page is a bit lacking in coverage of how to
> > use hotproc.  Maybe a tutorial page would suit here too?
> 
> Yes, that would be great. The use case I was thinking for the pidstat
> PMDA was that it would be suitable almost anyone to add certain
> processes to be monitored without necessarily knowing anything about
> PCP. For pidstat the required documentation to achieve this was more or
> less those two lines in the configuration file.

+1 ... pmdaproc is on-by-default already, and its hotproc metrics share
those goals - I think we should focus on adding anything that's missing
that you need into that PMDA.  Also, writing a pcp-pidstat and making
pcp-collectl mirror the behaviour you're seeking for OpenStack analysis
would also go a long way to making it user-friendly.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>