Re: [pcp] suitability of PCP for event tracing

[Nathan Scott <nathans at aconex dot com>]

----- "Ken McDonell" <kenj@internode.on.net> wrote:

> It has taken me a while to work through all of the issues here, not
> to
> mention more distractions than you could hit with a big stick.
> 
> Anyway putting an array of event records inside a pmResult is not
> going to be too hard - see http://oss.sgi.com/~kenj/event-params.html

| Event trace data includes the following for each event:
| timestamp
| event type
| event parameters (optional)
| The event type is really just another event parameter so we will not
| consider this as a separate data type, and event data consists of a
| timestamp and one or more parameters.

IMO, we also need Unique ID (refer X-trace and Dapper papers) and parent ID.
Preferably not optionally (could be inserted in PCP layers if no underlying
tracing support for end-to-end style tracing.

Not sure what the "event types" are you're refering to?  An example trace
(e.g. something simple - blktrace trace, or strace/ptrace info) encoded as
PCP results/PDUs would really help me here I think.

| We each of the data components to be a PCP metric, so we can leverage all
| of the metadata services to describe the type and semantics of the event
| data. So each data component would have a PMID (and a corresponding name
| in the external PMNS).

I think in practice this will prove a bit optimistic (so much data, classifying
it all - all parameters, flags, etc - to the tight PCP definitions ... not sure
this is really feasible, or needed).  I think a composite metric type like JSON
(readable) or perhaps XML might be a good option to provide for tracers.
Microsoft went with XML in ETW presentation tools FWIW, I think, but I'd lean
more toward JSON having coded both forms recently - they would have chosen XML
about 10 years ago and might not choose it a second time ;) given the chance.

| We need to accommodate an array of event records in pmResult to support polled
| retrieval where each pmFetch may return multiple event records. And the number
| of parameters per event record may not be fixed, e.g. when the number of
| parameters depends on the event type.
...
| An event parameter can then be encoded using a pmID (this metric needs to be

Hmmm ... seems a bit heavyweight to require a PMID per parameter.  Allocating
PMIDs dynamically is also quite tricky (cgroup stats in Linux PMDA does this,
so I recently coded something like that ... not alot of fun) and the numbering
space is limited.

Think I lost the plot shortly after this bit, that diagram sure would help.
Will talk soon.

cheers.

-- 
Nathan