This is on my list to look at Tommorrow, just ran out of time today.
Martins
> On Apr 20, 2015, at 4:57 PM, Nathan Scott <nathans@xxxxxxxxxx> wrote:
>
> 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
>
>
|