----- Original Message -----
>
> 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().
>
*nod*
>
> > 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
I'm trying to avoid that, as it means new code needed for each client.
Also, good chance some PMDAs will need filters that are quite complex
to specify on the command line (like scripts). Or with syntax that is
conflicting/awkward to use with shell syntax (back-quoting painful and
error-prone, so good to avoid that IMO).
> 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.)
Having to deal with multiple stores for one metric would ratchet up the
complexity considerably, on both client and server sides of the fence
(actually, I can't see a way to implement that at all, without having to
do a store before every fetch? - the server side doesn't know anything
about clustering/grouping on the client side, currently).
This seems like a pretty unusual corner case, I'm punting it'll suffice
to mandate separate contexts for such cases (which'll Just Work, as-is).
> > [...] 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?
*nod* wireshark filter?, on/off?, sql? - infinite other options. We
should ensure all of the above are readily achievable & allow people
using them to be creative in coming up with their own filter concepts.
I think the advantages of not having to worry about different types for
these metrics far outweighs the overheads (complexity, error handling,
round-trips to pmcd) of mandating strings only. So, I'm more and more
convinced we should opt for string-only filter metrics for this general
case. The option is always there to not use this mechanism, and have a
custom client/pmda interaction like we can today. But for a general
purpose mechanism, strings seem like the way to go to me.
cheers.
--
Nathan
|