nathans wrote:
> Goal: Transparent mechanism for client tools to perform a metric
> modification operation (likely a pmStore(3)) before starting to
> fetch values for metrics. This is to provide a per-user or per-
> monitor-host customisation (filtering) of the values returned. [...]
Just want to highlight the fact that as this would be additional state
stored at pmcd for the clients, it needs to be restored upon a
pmReconnectContext().
> Approach:
> Perhaps we could introduce known directories (/etc/pcp/filtered/ and
> $HOME/.pcp/filtered?) with files containing metric name:value mappings
> to store [...]
It seems likely that this filtering would be for ad-hoc purposes, with
possibly different filters in action for different clients. Thus,
hoping to make them persist in user- or especially system-wide default
files is probably not that helpful.
Maybe they could be left in files. Or maybe the pcp clients can earn
an additional option like pmevent, '-x [metric:]filter'. pmlogger
could grow some syntax to do the equivalent pmStores for each batch.
(It could make sense to filter the same metrics in multiple different
ways and log them at different rates.)
> [...] Should we mandate use of string metrics always for these
> things? (the one case we have that used integers could be done as a
> string instead, and its not yet released). [...]
Substring match?
Regular expression?
Arithmetic expression?
General PMIE predicate?
- FChE
|