pcp
[Top] [All Lists]

Re: pmParseMetricSpec(3) problems

To: nscott@xxxxxxxxxx
Subject: Re: pmParseMetricSpec(3) problems
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 01 May 2008 07:20:07 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <40997.192.168.3.1.1209514118.squirrel@xxxxxxxxxxxxxxx>
References: <40997.192.168.3.1.1209514118.squirrel@xxxxxxxxxxxxxxx>
Sender: pcp-bounce@xxxxxxxxxxx
I think these are both solvable.

>From a spec point of view (see PCPIntro(1))
a) eating multiple colons in the archive name is a no brainer
b) if neither host: nor archive/ is present the metric spec is still
valid, so disk.all.total and disk.dev.total[sda1] and
disk.dev.total[mydisk,yourdisk theirdisk] are all valid and refer to the
local pmcd's view of the metrics world.

>From an implementation point of view, a) is simple.  b) requires a bit
more research.

On Wed, 2008-04-30 at 10:08 +1000, nscott@xxxxxxxxxx wrote:
> Hi all,
> 
> I've mentioned the first of these issues to Mark before, but just wanted
> to get
> the word out to a wider audience, in case someone else can fix this for
> me. :)
> 
> I've come across two issues in pmParseMetricSpec(3).  The first is that it
> does
> not do the right thing for (archive) file names containing a colon (:) -
> these it
> treats as a hostname (up to the first colon).  This is not that uncommon
> since
> archives might well be named containing HH:MM notation for hours/minutes,
> as kmchart once did for its recordings.
> 
> Second, I've just recently come across the fact that theres no way to specify
> use of the local context through this interface - it handles only hostnames
> and archive filenames in its parsing, and the API "int isarch" parameter
> makes
> resolving this quite tricky.
> 
> I'm not sure how best to fix this one.  It may be that we need a new
> interface
> here, which allows all context types to be passed in?  Or could we change the
> "int isarch" field to be the context "int type" and also make
> localhost:/metric[]
> to mean local context?  (the latter bit seems quite dodgey to me - but I
> don't
> see a better way).
> 
> cheers.
> 
> --
> Nathan
> 
> 


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