G'day Marko.
This is simpler for disk.dev.avrqsz:
disk.dev.avrqsz = 2 * rate(disk.dev.total_bytes) / rate(disk.dev.total)
(we already have metrics that return read+write bytes and read+write IOPs
and putting the 2 * at the front is a little clearer IMHO to do the Kbytes
-> blocks conversion, although I would argue that sar has got this wrong
forever and the answer should be in bytes (or Kbytes) not "blocks")
I don't think avqsz is correct. read_rawactive and write_rawactive measure
time during which disk requests are being serviced ... these are in units
of milliseconds, so you need to divide by 1000 to get close to the sar
numbers.
BUT because there are so many ways to calculate the "average queue length"
(this one is the time average, not the stochastic average) and most punters
don't understand the differences I have always argued that this metric
hinders, does not help, performance analysis. See
man/html/howto.diskperf.html (in the PCP source tree) for a much longer rant
on this subject.
Based on symmetric, we probably should also have disk.dev.total_rawactive
exported from the PMDA ... I'll attend to this.
For disk.dev.wait you can use disk.dev.total instead of
disk.dev.read+disk.dev.write.
The "library" of derived metrics is a work in progress ... I'm still not
sure of the right way to do this. For most users (maybe) there does not
seem to be a case to warrant loading a bunch of derived metrics every time a
PCP client is started, so I'm not sure a "library" that is always processed
is the correct approach. There is also an issue of potential name clashes
between the derived metrics and the evolving PMDA metrics and indeed between
the derived metrics themselves.
My current thoughts are to extend $PCP_DERIVED_CONFIG to be a $PATH-style
list, and then if a directory appears in the list, all the files in that
directory will be processed as though they are derived metric specification
files. This is (a) backwards compatible, (b) optional, and (c) gives a
short-hard way of naming a bunch of derived metric files.
I'd greatly appreciate feedback on this "library" of derived metrics
suggestion.
> -----Original Message-----
> From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On Behalf
> Of Marko Myllynen
> Sent: Thursday, 25 June 2015 5:24 PM
> To: pcp developers
> Subject: [pcp] Derived Metrics with rate()
>
> Hi all,
>
> thanks to Ken, the new rate() keyword is now available in 3.10.5 so I
tried to
> write derived metrics for the three sar metrics not provided by default
by PCP
> (since they are, well, derived).
>
> With sar -d 1 and with each of PCP_DERIVED_CONFIG=./metrics.conf pmval
-t
> 1s -f 3 disk.dev.{avrqsz,avqsz,await} I'm getting similar results with
these
> calculations:
>
> disk.dev.avrqsz = ((rate(disk.dev.read_bytes) +
> rate(disk.dev.write_bytes)) / (rate(disk.dev.read) +
> rate(disk.dev.write))) * 2
>
> disk.dev.avqsz = disk.dev.read_rawactive + disk.dev.write_rawactive
>
> disk.dev.await = 1000 * (rate(disk.dev.read_rawactive) +
> rate(disk.dev.write_rawactive)) / (rate(disk.dev.read) +
> rate(disk.dev.write))
>
> Before starting to write any other derived metrics (*) I wanted to check
how
> does this look like to you, are they what you'd expect or would you
write any of
> them somehow differently? Any other comments or suggestions?
>
> *) I'll concentrate more on some derived metrics metrics from custom
PMDAs
> so nothing to share but if the earlier idea of default derived metrics
"library"
> provided PCP sounded something that could be done, the three derived
metrics
> above could be included there.
>
> Thanks,
>
> --
> Marko Myllynen
>
> _______________________________________________
> pcp mailing list
> pcp@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/pcp
|