| 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> |
|---|---|---|
| ||
| Previous by Date: | [RFC] A privileged pmcd co-process, Nathan Scott |
|---|---|
| Next by Date: | Re: [RFC] Command pipe PMDA, Frank Ch. Eigler |
| Previous by Thread: | Re: [pcp] PCP Network Latency PMDA, Nathan Scott |
| Next by Thread: | Re: PCP Network Latency PMDA, Frank Ch. Eigler |
| Indexes: | [Date] [Thread] [Top] [All Lists] |