Re: [pcp] suitability of PCP for event tracing

[nathans at aconex dot com]

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

> On Fri, 2010-12-03 at 16:32 +1100, nathans@aconex.com wrote:
> > 
> 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

Don't think pmid matters, since name would be used by tools.

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

Yep.

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

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

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

cheers.

-- 
Nathan