Re: [pcp] suitability of PCP for event tracing

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

kenj wrote:

> [...]  I am assuming there is at most one source of event records
> per PMDA, which I think is OK (event records are of variant type,
> with the number of parameters being different, possibly based on
> event type) [...]

This sounds fine.  In stap land, we could adapt to either variant
types or multiple PMDAs with non-variant types.


> >For the former, it seems we'd need at least three functions in pmapi.h
> >to be forwarded to the pmda: one to start watching metrics of
> >interest, one to poll any values collected since last time, and one to
> >shut down the watch.
> 
> I have not considered the register (and filter if they are separate) and 
> unregister functions.  pmStore is the existing way to push this sort of 
> thing to a PMDA.  [...]
> ....  pmStore leverages existing protocols and can be used to both start 
> watching (register in my speak) and shutdown (unregister in my speak). 
> Is there something else that is needed that could not be implemented 
> using pmStore and "control" variables to set (and possibly return) the 
> status/profile/registration of current events of interest?

first pmda->pmStore (foo.bar.register, VALUE)
later pmda->pmFetch (foo.bar) -> { bunch of queued foo.bar events }
later pmda->pmFetch (foo.bar) -> { bunch of queued foo.bar events }
 last pmda->pmStore (foo.bar.unregister, 0)  # or .register = 0

That is probably fine, as long as the context-passing /
cleanup-callback data is available.

The initial .register VALUE offers some interesting possibilities.
Since they are typed, could we interpret the VALUE as a promised
polling interval?  Or buffer size?  Or event count?  (Or, if this is
itself a structured type, a filtering predicate!)

> There is no need to poll ... pmFetch will return a pmResult with numval 
> indicating if there are any event records in the pmResult payload.

(Right, the pmFetch would be the poll function.)


> [...]  It would help me provide some concrete understanding of your
> planned use cases if I could see some sample code that enables,
> collects and disables the sort of event records (or traces) you're
> considering. [...]

We have not worked out the most natural systemtap lingo to encode the
PCP metric / domain / forthcoming event mappings, since we're
infinitely programmable, so don't have to hard-code it all yet.
But to help think about it, consider a system call trace metric
"process.all.syscall" that returns events of the same general form
that strace gives: a timestamp, a pid, an entry/exit indication,
parameters/result values.  Obviously this would be a high-volume
event.

A similar "process.perpid.syscall", would carry events with a pid# as
a pcp instance variable.  For efficiency, we need to figure out how
the registration-time pmStore should identify the requested instance
numbers, so that other processes need not be affected.

A similar "process.percall.syscall" could be indexed by syscall#.
Whether composing .perpid.percall etc. makes sense within a PCP
client, dunno.

(We'd also have process.*.syscall.stats type metrics to return
rates/counts in a normal polled manner.)

A simple alternative that may serve many purposes may be nothing but a
timestamped lump of text constituting the event, like lines from a log
file or pipe, or unstructured printf()s from a systemtap script.


- FChE