Re: RFC: metric labels as first-class PCP concept

kenj wrote:

> Tardiness is not lack of interest, I've been thinking ... [as] it takes
> a little longer these days as my PCP engagement is pro bono.

Thanks for sparing time.


> [...]
> I think it is going to be really important to get straight in the
> beginning the _scope_ for labels.  I can see the following possible
> taxonomy (it is not really a hierarchy as the metric and instance
> "levels" are orthogonal):
> 1. context (the global stuff)
> 2A. metric (common to all instances of a given metric)
> 2B. one or more instances within an instance domain (common to those
> instances across all metrics that share the instance domain)
> 3. metric-instance (unique to a specific metric-instance pair)
>
> Before delving too deep into the PMAPI requirements, this needs to be
> agreed to (are all 4 going to be supported?) 

Good question.  We haven't seen many worked-out examples of the
different classes of labels.  (lberk's examples were great, but only
seemed to represent the 'global' class, which wouldn't originate from
PCP but a sysadmin's files anyway).


> and then what are the semantics for a label that is redefined (with a
> different, or possibly the same) value in another place?  For example,
> cute="foo" with the metric X (over the InDom I), and cute="bar" with
> instance i of InDom I, and cute="no clue" with instance i of metric X.

In the instance ~= metric-label model I proposed, this wouldn't arise,
since if a metric-instance label changes, it becomes a different time
series with a different instance number.


> And a somewhat related issue is points in time where the labels change
> (a label is added or deleted, or a value for a label changes) ... what
> happens for: [...]

Exactly.  IMHO, the less conceptual reinvention here, the better.


> [...]  Label-based filtering => label expressions involving values,
> value ranges, value sets, regular expressions over values, relational
> operators (==, !=, >, <, ...), boolean operators (&&, || and not),
> etc. Once you have this, the existing instance profile could become a
> instance=<expr> under the hood and exposed as an alternative
> specification method at the PMAPI.  This would promote the instance
> profile to a first-class label concept, rather than presenting two
> different filtering methods.

Before one gets to this level of detail, one would need to contemplate
who does the filtering and when/where.  I outlined a way where filtering
is done entirely client-side (via a sequence involving selection of
metrics and via instance profiles).


> Some other thoughts:
> [...]
> I have no idea what the format/contents of <basename>.labels would be,
> particularly if a specific label value might vary in time (over the
> life of the archive) like a dynamic instance domain.

If talks like a metric, and it quacks like a metric, consider making it
a metric.


- 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 (#14808): https://groups.io/g/pcp/message/14808
View All Messages In Topic (15): 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
-=-=-=-=-=-=-=-=-=-=-=-