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
-=-=-=-=-=-=-=-=-=-=-=-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.