pcp
[Top] [All Lists]

Possible problem with event record mechanisms

To: David Smith <dsmith@xxxxxxxxxx>
Subject: Possible problem with event record mechanisms
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 10 Mar 2011 08:57:08 +1100
Cc: pcp@xxxxxxxxxxx
In-reply-to: <4D77E842.2080802@xxxxxxxxxx>
References: <4D6D0D30.2060507@xxxxxxxxxx> <1299010797.21904.40.camel@xxxxxxxxxxxxxxxx> <4D6D7799.6000305@xxxxxxxxxx> <1299023775.21904.50.camel@xxxxxxxxxxxxxxxx> <4D6E5DEF.2090404@xxxxxxxxxx> <1299563074.21904.68.camel@xxxxxxxxxxxxxxxx> <4D77E842.2080802@xxxxxxxxxx>
Reply-to: kenj@xxxxxxxxxxxxxxxx
On Wed, 2011-03-09 at 14:51 -0600, David Smith wrote:

> Thanks.  What's checked in now handles a single logfile and multiple
> consumers.  Now I'm expanding it to handle multiple logfiles (via
> instances) and multiple clients.
> 

OK, with instances we may be heading for a problem in paradise ...
implicit in everything I've done so far is an assumption that event
record metrics are singular (only one instance, namely PM_IN_NULL) for
each metric.

I ripped all of the instance stuff out of pmval in making pmevent. This
was when I realized that numval == 1 is required for each of 
__pmDumpEventRecords, __pmCheckEventRecords, pmUnpackEventRecords in
libpcp.

I had been assuming that rather than an instance domain, dynamic metrics
could be used to export multiple sets of event records from a single
PMDA, but for your logfile dredging PMDA this probably won't work well.

If there is a genuine use case where event records exported for a single
metric with multiple instances is needed, we need to circle back and
reconsider the assumptions in the libpcp code.

I've expanded this mail to include the broader list to solicit feedback.

<Prev in Thread] Current Thread [Next in Thread>