----- Original Message -----
> The status quo just seems wrong ... anything that can change the state
> of pmlogger should not be in the "enquire" class. Shall I fix this?
Yes please! :)
> Locking down pmlc is unlikely to have any negative fallout.
>
> I believe pmlc use is very rare, probably because I have not managed to
> convince anyone else that the "value add" proposition for pmlc in the
> following scenario is real:
The other scenario, where I've seen pmlc used (as in: really used, not
a hypothetical scenario) is to query/check "is pmlogger really logging
the things its meant to be" - so extending to the "is pmlogger running
at all" checks.
> * pmlogger configured with shallow metric coverage and long sample intervals
> * pmie looking for badness
> <badness happens>
> * pmie rule fires to ...
> use pmlc to increase metric depth and/or reduce sample interval
> wait a while
> use pmlc to return pmlogger to default configuration
*nod* - have never seen this used in the wild FWIW. But, high volume
event metric data could make a stronger case for this model, which is
potentially much more of a firehose than regular sampled data - so an
on/off logging switch is more compelling.
> Even for this scenario, one could use a second pmlogger instance and
> later merge the two archives with pmlogextract, avoiding pmlc altogether.
*nod* - its all a bit manual though, whereas the above is more neatly
automated (eg we could enable that sort of thing in a default install
if some common situation came up, whereas this latter model would be
possibly a little more awkward to integrate).
cheers.
--
Nathan
|