| To: | Nathan Scott <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] RFC: allowing longer metric and instance names in MMV(5) format |
| From: | Ryan Doyle <ryan@xxxxxxxxxxxx> |
| Date: | Wed, 29 Jun 2016 18:08:37 +1000 |
| Cc: | Paul Smith <psmith@xxxxxxxxxx>, Ryan Doyle <rdoyle@xxxxxxxxxx>, Suyash <dextrous93@xxxxxxxxx>, Lukas Berk <lberk@xxxxxxxxxx>, pcp developers <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <354261953.2889296.1467178515176.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <354261953.2889296.1467178515176.JavaMail.zimbra@xxxxxxxxxx> |
| User-agent: | Roundcube Webmail/1.1.4 |
On 2016-06-29 15:35, Nathan Scott wrote: The fundamental problem is that the "on-disk" metric and instance types for MMV encode the names in a 64 byte character array. So, I'm suggesting we support an optional (non-default) v2 MMV format which would be exactly the same as v1 except that metric/instance structures could specify the offset to a mmv_disk_string_t for the name (instead of embedding it directly). +1 If a metric/instance name is presented that is too large to fit in v1 format, the client library could transparently switch to using v2 format and continue on. I wonder if the backwards compatibility is worth it? Seeing as we have a version number in the header of the MMV, perhaps the expectation is that if you are using V2, your instances, metrics and indoms are in the correct format for that version (using the string offsets). The MMV PMDA would of course be able to decode either version. Thoughts? Ryan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC: allowing longer metric and instance names in MMV(5) format, Paul Smith |
|---|---|
| Next by Date: | [Bug 1350816] proc.psinfo.rss is incorrect with threads enabled, bugzilla |
| Previous by Thread: | Re: RFC: allowing longer metric and instance names in MMV(5) format, Nathan Scott |
| Next by Thread: | RE: [pcp] RFC: allowing longer metric and instance names in MMV(5) format, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |