Hi -
> I somehow misunderstood the scope of derived PCP metrics. It make
> sense if taking into account PCP design philosophy not to keep
> monitoring client state information.
This part is not actually related to derived-metrics - the same
rate-conversion (or absence of ...) affects basic metrics too.
> Our interest in PCP as a on-demand tool was mainly due to this
> design. We don't want to have another tool on the system collecting
> system stats and adding overhead. We want to use PCP as a
> troubleshooting tool where high resolution data collection is
> triggered on-demand basis to debug the issue.
Right. At this point, the on-demand aspect is not well automated, but
it's not hard to assemble something yourself. One way to do that is ...
Create a configuration/storage directory:
% mkdir on-demand-pmmgr
% echo HOST1 >> on-demand-pmmgr/target-host
% echo HOST2 >> on-demand-pmmgr/target-host
% echo HOST3 >> on-demand-pmmgr/target-host
# and/or engage /target-discovery
% echo "-t 1" >> on-demand-pmmgr/pmlogger # sampling interval
% touch on-demand-pmmgr/pmlogconf # to run pmlogconf to configure logger
# else make your own, and add -c FOO
# to the /pmlogger file
Run the daemons:
% pmmgr -c on-demand-pmmgr &
% pmwebd -p PORT -G -R .../jsdemos -A on-demand-pmmgr &
% firefox http://localhost:PORT &
When finished:
% kill %1 %2 %3
% rm -rf on-demand-pmmgr
That's all there is to it: it does not require special privileges or
interfering with system services.
> With PCP graphite integration, we also like to evaluate PCP
> archives/logging feature as a replacement to sar to log historical
> data. [...]
Great. (If you want to merge together data from multiple logging
configurations into a single pmwebd graphite dataset, you'll need to
give a -A path that includes both background and on-demand sets.)
> Question:
> I want to make we are implementing the logic on web client correctly. Let's
> say PMAPI client is fetching metrics at a second interval. To process it
> one show do the following:
>
> - fetch the given metric, say kernel.all.cpu.idle
> - calculate the delta
> - Apply rate conversion. [...]
Yes. (You'd want to use the actual timestamps of prior samplings of
the same metrics to calculate rates, not the theoretical http-level
refresh interval.)
- FChE
|