Hi guys,
----- Original Message -----
> On 15/04/14 05:27, Martins Innus wrote:
> > ...
>
> Thanks for the insight Martins.
>
> Well this is truly interesting. Your use case is something that has not
> previously been encountered in over a decade of belting PCP in
> production environments. I find that both surprising and exciting.
:)
> I can't see a way to achieve what you want with the single pmlogger
> process and the capabilities today. This is because the log mandatory
> pmlc command updates the logging state for all the named metrics within
> pmlogger, so what you describe is what I'd expect to happen.
>
> The options are:
>
> 1. extend pmlc and pmlogger to have an additional set of metrics that
> can have duration and logging state that co-exists with the config file
> ones at startup (so the state change from pmlc is independent of, not a
> replacement of, the original state) ... it would be nice to have some
> short hand notation for turning all of these additional metrics off in
> one command and extend the "once" duration to allow N times.
> ...
> Given you can do 2. today, and it would take me a couple of days to get
> 1. to a prototype state, I'd vote for 2.
>
> And in the mean time we should consider the discussion to see if we can
> refine 1. into something that is general useful, robust and easy to use.
>
I like the direction #1 is headed also.
I wonder if a concept of groups of metrics would be useful here (IOW, user
defined, named groups) - so not only the one additional set. There may be
different problem scenarios that someone is trying to focus on, problem A
might want to catch a set of proc metrics, problem B maybe some mem state,
problem C a third set ... switching on/off these groups via pmlc commands
that pmie could latch onto simply via "enable setB, interval X", "disable
setB" and so on, could be quite neat.
cheers.
--
Nathan
|