pcp
[Top] [All Lists]

Re: [pcp] PCP Network Latency PMDA

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] PCP Network Latency PMDA
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Mon, 23 Jun 2014 10:12:16 -0400
Cc: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <223453324.31184588.1403489511833.JavaMail.zimbra@xxxxxxxxxx>
References: <53A34A47.3060008@xxxxxxxxxx> <53A352FF.9090906@xxxxxxxxxxxxxxxx> <y0m7g4c9wcp.fsf@xxxxxxxx> <1241706054.31171165.1403487302812.JavaMail.zimbra@xxxxxxxxxx> <20140623014102.GI8337@xxxxxxxxxx> <1830537766.31176499.1403488150780.JavaMail.zimbra@xxxxxxxxxx> <20140623015408.GJ8337@xxxxxxxxxx> <223453324.31184588.1403489511833.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

> > I don't think anyone was suggesting an all-or-none sort of collection
> > behavior.  I only said on-demand, referring to the metrics actually
> > requested by a client (suffering PM_ERR_VALUE or PM_ERR_AGAIN or
> > PM_ERR_PMDANOTREADY or whatever for that first pmFetch).
> 
> Its common for someone to run something like "pminfo -f network" to get
> a high level look, then browse through the result, maybe iterating on
> further with pminfo to something more specific, or switching to pmchart
> or another tool for a different view.

I think it's reasonable for such one-shot clients to suffer from the
indignity of a PM_ERR_PMDANOTREADY for such metrics.  (That's not too
surprising, considering that the semantics would probably be COUNTER,
which are meaningless in isolation.)

- FChE

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