Hi,
On 2015-04-20 23:57, Nathan Scott wrote:
>> On 2015-04-20 14:22, Nathan Scott wrote:
>>
>> 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.
hmm, so it is possible to provide a redirected metric from another
domain in C but is there a way to do that in Perl or Python? And is it
possible to read a metric from another domain to be used to calculate or
construct a new metrics in the current domain, not just redirect?
>>> 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).
Yes, the values are basically proc.io.{read,write}_bytes / process
lifetime-in-seconds. So it's a calculated / pre-processed value which
quickly gives an idea of a process IO activity at a time. (See below for
more on this.)
FWIW, the upstream man page for everything under proc is nowadays
well-maintained: http://man7.org/linux/man-pages/man5/proc.5.html.
>> 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.
Agreed, and wrt documentation it should not be the case that it's easier
to write a new PMDA then to decrypt an existing one :-)
Wrt usability in general, the above mentioned metrics read/s and write/s
can of course be calculated based on the process lifetime and read/write
totals so far. But if using something like pmval to quickly check what
the process is up to at the moment, you don't get that sort of idea
instantly.
This is of course not specific to monitoring processes but applies in
general, what's the best practice to follow a metric which actually is a
combination or calculation of two or more metrics being collected?
> Also, writing a pcp-pidstat
I don't think this is really needed as long as something similar is
easily available either from hotproc or pidstat PMDA.
Thanks,
--
Marko Myllynen
|