nathans wrote:
>> [...]
>> 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.
To some extent, OTOH we already have some common command line argument
parsing/handling in libpcp.
> Also, good chance some PMDAs will need filters that are quite complex
> to specify on the command line (like scripts).
So instead of passing arguments on the command line, you'd imagine
passing arguments in a temporary file? That's not unheard of (like
DOS's @FILE), but usually thought of as a last resort.
>> (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 [...]
> 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).
Yes, I was thinking of multiple contexts for them, but that wouldn't
help if libpcp automagically pulled in the same default filter files
for them all.
>> > [...] 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.
Back up a bit. It would help to give a worked-out example or three
about what these could look like. Obviously, the more specialize the
filtering, the more it has to be pushed toward the PMDAs and/or
clients, but OTOH that makes the PMAPI / pmcd contribution rather
slim or even zero.
- FChE
|