On 15/04/14 05:27, Martins Innus wrote:
...
Playing with pmlc, i can do a:
log mandatory on once <list of all my existing metrics>
to force a logging event when the compute process starts, but then the
logger stops its regular logging schedule. So I assume then I have to
write a script that parses the logger config file and re-enables the
logging as it was with pmlc commands? I didn't see a save/load config
set of commands from pmlc unless I missed it.
I can go down that path if that is the right way to do it. But I was
hoping for some sort of "log this list of metrics right now, just once,
but don't otherwise change pmlogger" command.
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.
2. Have your script that is currently calling pmlc actually launch a
_new_ pmlogger to capture just the metrics you want at the start or end
of the computation or with some particular frequency during the
computation. Then at the end of the day, you can use pmlogextract to
merge together the archive from the default system logging (or whatever
pmlogger you're pointing pmlc at) with one or more archives from your
computation runs. The merged archive will be the same as if 1. was
implemented.
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.
|