Re: [pcp] suitability of PCP for event tracing

[Ken McDonell <kenj at internode dot on dot net>]

On Fri, 2010-12-03 at 16:32 +1100, nathans@aconex.com wrote:
> 
> Yeah, sounds like this could indeed work & would be alot more flexible.
> Not sure about the name "anon", nor the one metric per type, wouldn't
> it be better to have specific metrics for the specific items we know we
> need (so far, nmissed and flags, both of which would be u32 as well).
> Then we can make the units/semantics/type make sense too.
> 
> And meaningful names like event.record.missed and event.record.flags
> (or something like that) might give a bit more of a clue as to what
> they are than anon.
> 
> > I'd appreciate thoughts on this.

Since I wrote the original "anonymous" metrics mail, I've done an
implementation and got everything working and passing QA (the latter was
harder than the former).

Instead if always polluting the PMNS with anon.* metrics, I've made a
less intrusive change that introduces pmRegisterAnon(void) to explicitly
add the derived metrics for 3 anon metrics (32, 64 and DOUBLE).  So I
still have anon.32 et al in the PMNS.

Now if we wanted to allow arbitrary names for the anon metrics, then I
think pmRegisterAnon would have to be expanded ... below is overkill

int
pmRegisterAnon(char *name, pmID pmid, pmInDom indom, int type, int sem,
pmUnits units)

but would allow one to specify the additional metadata that cannot
necessarily be deduced from a name like "event.records.flags" ... now
some of these can be dropped by making unilateral decisions

pmid	- does it really matter? pmRegisterDerived (which sits behind all
of this) makes the allocation in a way that avoids duplicate PMIDs

indom	- there is no place of anonymous indoms in all of this,
PM_INDOM_NULL is the only choice here

sem - since there are no PMDA-provided values, we could drop this also
and stick with PM_SEM_DISCRETE as per what I've implemented

units - same argument as for sem, make this all zeros.

which reduces it to

int
pmRegisterAnon(char *name, int type)

which is not that different from what I've done.

How would that work?

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).