https://bugzilla.redhat.com/show_bug.cgi?id=1337102
--- Comment #1 from Nathan Scott <nathans@xxxxxxxxxx> ---
(In reply to Marko Myllynen from comment #0)
> Description of problem:
> When doing something like this after starting the pmlogger service using the
> default configuration:
>
> echo "log mandatory on 10sec kernel.all.load" | pmlc -P
> echo "log mandatory on 10min kernel.all.load" | pmlc -P
>
> pmlogger logs these logging changes in its logs (rightly so). However, if
> doing the latter several times in a row (for example for a script) pmlogger
> would still log the current state even if there was no change at all in
> logging configuration making the log messages redundant.
>
> While one could use "query" to determine the current status and then call
> pmlc only if needed. But parsing pmlc output and adding logic whether or not
> to call pmlc doesn't sound optimal in this case and doesn't guarantee that
> all calls to pmlc are done after such checks.
>
It's very unlikely pmlogger is going to be able to figure this out I think -
the way it groups sets of metrics, the different intervals, and the different
starting offsets above - all conspire to make this a difficult problem to solve
in the general case.
I assume you are doing this pmlc invocation from pmie? (not really mentioned
here, but IIRC that was mentioned elsewhere)
If so, it might be simpler to manage the state there to avoid this situation.
Either using the action holdoff logic, or using a script that holds state in
the filesystem, or a combination of those and/or your pmlc query idea. I've
seen cases where people wrote custom PMDAs with storable metrics indicating to
pmie whether certain situations currently hold (like, we have currently logging
X at Y interval from pmlc), so that it can choose to take additional action or
not.
Lots of options, so I suspect changing pmlogger for this is probably not going
to happen. (Although, if someone with deeper pmlogger-fu than I have thinks
its feasible - please go ahead!).
cheers.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=a4zfeJNvSW&a=cc_unsubscribe
|