Hi,
On 2015-05-08 05:27, Ken McDonell wrote:
> On 07/05/15 20:29, Marko Myllynen wrote:
>> ...
>>> And I'm not sure why the /100 is required, could you please explain
>>> that part?
>>
>> kernel.all.uptime is in seconds but hotproc.psinfo.start_time is in
>> jiffies and although jiffies-to-seconds is not necessarily a trivial
>> operation [1], /100 seemed to provide "close enough" results during my
>> tests. ...
>
> Be careful. We (in PCPland) try very hard to avoid platform-variant and
> decade-variant units of measure ... blocks and hz and jiffies are all in
> this bag.
>
> So no matter what units the base instrumentation is in, the PMDA is
> responsible for translating it to something useful and invariant ...
> like seconds in this case.
>
> But unfortunately in this case the PMDA implementor says the metrics are
> seconds, but they are not (see the example below) ... this is a BUG ..
ok, I admit I didn't pay that much attention to units, it looked like
the jiffies value under /proc so I just went ahead with the calculation.
> the PMDA should return hotproc.psinfo.start_time either /100 and call it
> seconds or *10 and call it msec (and increase it to 64-bits in this case).
>
> If this was fixed you would not need the /100.
I'll file a bug next week if nobody beats me.
>> It would be nice to be able to write this as:
>>
>> mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime
>> mytest.marko = hotproc.psinfo.rss / mytest.divisor
>
> I don't think nested definitions are going to happen ... the code behind
> this is already pretty complex ... but I could entertain a pmie-style
> macro definition and substitution that would achieve the same effect.
That'd be great. One more thing that occurred to me that might be
useful, especially if we were to create that "library of derived
metrics" or such, I'd like to do this in my own derived metric
configuration file:
$include /etc/pcp/derived-metrics.conf
mytest.test = ...
mytest.foo = ...
Mostly a matter of convenience again and certainly nothing critical but
if the provided "library of derived metrics" would grow over time, it
might also make sense to split it to separate files and then use
includes there, too.
Thanks,
--
Marko Myllynen
|