| To: | Nathan Scott <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] PCP Network Latency PMDA |
| From: | "Frank Ch. Eigler" <fche@xxxxxxxxxx> |
| Date: | Sun, 22 Jun 2014 21:54:08 -0400 |
| Cc: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <1830537766.31176499.1403488150780.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> |
| User-agent: | Mutt/1.4.2.2i |
Hi - > PMDAs can export many metrics, some may be expensive others not. > [...] It exports many other metrics, and enabling every single > expensive metric that might make sense for it to export, simply > because pminfo connected and asked for a value (of an unrelated > metric) would not be sensible. 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). - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] PCP Network Latency PMDA, Nathan Scott |
|---|---|
| Next by Date: | Re: [RFC] Command pipe PMDA, Nathan Scott |
| Previous by Thread: | Re: [pcp] PCP Network Latency PMDA, Nathan Scott |
| Next by Thread: | Re: [pcp] PCP Network Latency PMDA, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |