Re: RFC: metric labels as first-class PCP concept
"Frank Ch. Eigler" <[email protected]>
| Newsgroups | gmane.comp.sysutils.pcp |
|---|---|
| Message-ID | <[email protected]> |
Hi - On Wed, Nov 23, 2016 at 03:25:18PM -0500, Nathan Scott wrote: > [...] > > > You can't hide those awful instance names > > Yes, you can. > Not in these cases [old clients] names that they see (from remote > hosts or newly created V.2 archives) cannot, and will not, be turned > into such a mess. [...] That is a reasonable point, though can be overcome by any of - making labels optional via client version detection - grinning and bearing it - after all, the sorts of indoms that we'd want to decorate with instance-specific labels are those that are already pretty ugly / compound - using another kludge ^W hack ... say, if we're contemplating peer metrics already for the metric-level labels, that same metric could carry a parallel indom for the base metric. The base metric's indom could carry the pure unadulterated strings, and the peer metric's parallel indom could carry the structured JSON label version. Then an old client such as an old pmlogger would see the old names. A new one would see both. This could be hidden in new libpcp client-side api, again with zero archive format or network protocol changes. > [...] > > > Labels are really a separate metadata concept. [...] do it cleanly. > > Again, they are a separate metadata concept - much closer to pmDesc fields > (analogous to inode stat(2) data in earlier filesystem extended attributes > comparison) than to full metrics. > A metric is a very heavy weight thing (namespace, PMIDs, indoms, > instances, pmDesc, help texts) - labels are not that at all. And yet a common pmda manages to define a new metric with a few dozen lines of code in C, or a handful in perl/python. They don't have any other "weight". > > You also mentioned the need to vary labels - that necessitates treating > > them as values along a timeline, just like normal metrics. > > Much lighter weight though - labels are a concept closer to > instances than metrics, which also change along the same timeline. I already dealt with instances (those are already timeline-sensitive). This part was referring to metric-level labels, storeable in peer metrics. > It seems one unexplored area needing discussion is filtering. I'll > follow up on that in a separate thread, as that is a big topic and I > want to look at filtering solutions beyond labels as well. That is essential. Labels only provide value if they can be efficiently searched. - FChE -=-=-=-=-=-=-=-=-=-=-=- pcp mailing list [email protected] https://groups.io/g/pcp/messages -=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#14801): https://groups.io/g/pcp/message/14801 View All Messages In Topic (13): https://groups.io/g/pcp/topic/3188520 Mute This Topic: https://groups.io/mt/3188520?uid=174580 New Topic: https://groups.io/g/pcp/post Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580 Group Home: https://groups.io/g/pcp Contact Group Owner: [email protected] Terms of Service: https://groups.io/static/tos Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy -=-=-=-=-=-=-=-=-=-=-=-