Re: [pcp] suitability of PCP for event tracing

[Ken McDonell <kenj@internode.on.net>]

On Fri, 2010-12-03 at 20:40 +1100, nathans@aconex.com wrote:
> ...
> > which reduces it to
> > 
> > int
> > pmRegisterAnon(char *name, int type)
> > 
> > which is not that different from what I've done.
> > 
> > How would that work?
> 
> Sounds fine.  Perhaps this should be an __pm routine though (this
> all sounds libpcp internal, right?) ... __pmRegisterStaticMetric?
> Or something along those lines.

Nod ... I like the "anonymous" adjective, so __pmRegisterAnon is likely
to be it.

> > Making the pmRegisterAnon() prototype more complicated than this
> > "minimalist" version would be real difficult given the way this is
> > spliced into the derived metrics definition parser, so I'd rather not
> > do
> > that unless there is a strong case (which the events record scenario
> > certainly does not suggest).
> 
> Shouldn't be a problem ... it seems an internal thing rather than a
> general-purpose user-exposed thing, so not really a problem that it
> allows the limited configurability.  The two uses we have would both
> have u32 metrics, I think ... so you could even drop the type at the
> current time and add it later if needed.

This is likely to be useful to a pmResult rewriter, so I'd rather keep
the type argument just in case ... it adds almost no complexity to the
implementation.

> Stepping back a bit, do we need to worry about the situation where we
> have multiple PMDAs (different domains) exporting trace data?  Is the
> one PMID for thee metrics sufficient?  (there is only ever data in an
> event record array from one PMDA, correct?)pmUnpackEventRecords,

I don't think PMDAs can ever emit these things ... they should use the
metrics they really know about, else the additional control information
in a pmEventRecord ... and on this topic, I'm moving to yet another
encoding of "missing records" in a pmEventRecord (if er_flags is
PM_ER_FLAG_MISSED then er_nparams is the number of missed records, not
the number of parameters for an event record).

The only place we're going to see the anonymous metrics is in the output
pmResult from pmUnpackEventRecords, which means pminfo -x, pmdumplog,
pmlogger, pmlogextract will all have to know about them, but no PMDA
should be using this stuff.

I think this will work OK in the multiple PMDAs emitting event trace
data as event.flags and event.missing will be defined once and used by
pmUnpackEventRecords for all the PM_TYPE_EVENT data, no matter where it
comes from.

I sense I'm converging on something that is close to done here in terms
of definition ... thanks for your help and feedback.