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

Heya Lukas,

----- Original Message -----
> Hey,
> 
> I think overall this makes sense, a couple of thoughts inline.

Taa.

> "Nathan Scott" <[email protected]> writes:
> > So, the proposed approach is:
> > a/ keep the existing PCP metric and instance concepts unchanged - including
> >    naming and pmDesc metadata;
> > b/ extend those ideas with an (optional) "label" concept, allowing
> > name=value
> >    pairs to be associated with metric values.  In a sense, labels would be
> >    similar to filesystem extended attributes;
> > c/ see labels as primarily static and optimise for that case, while
> > allowing
> >    for some dynamic change (much like we do with PCP instance names).
> 
> How were you envisioning making the dynamic changes? Something similar
> to a pmstore --label command? I think this will be important for cases
> where the default has been set in ../labels.d as well as if there is a
> general state change of labels (ie, 'deployment' label changes from
> 'staging' to 'production' or something similar).

From all the examples I looked at, the only dynamic change I could see in
the use of labels on other projects was at that top (context) level - and
there we can handle it like any other metric (its a pmcd.labels fetch).

For the per-metric labels, in all cases I've seen those are more like our
regular (pmDesc) metadata - fixed in stone.  The one case that's not like
that was the cgroups example, where label need to match to the associated
instances.  For that case, I'd think we would handle change like we do in
the new/removed instance case - have pmlogger request the (changed) label
at the same time as it requests the new set of instances.

> [...]
> > $ pminfo -dfl cgroup.cpuacct.usage_percpu
> >
> > cgroup.cpuacct.usage_percpu
> >     Data Type: 64-bit unsigned int  InDom: 3.22 0xc00016
> >     Semantics: counter  Units: nanosec
> >     inst [0 or "/::cpu0"] value 7137875587296 labels cgroup="/" cpu="cpu0"
> >     inst [1 or "/::cpu1"] value 3539695017434 labels cgroup="/" cpu="cpu1"
> >     inst [2 or "/system.slice::cpu0"] value 407816293372 labels
> >     cgroup="/system.slice" cpu="cpu0"
> >     inst [3 or "/system.slice::cpu1"] value 202747983510 labels
> >     cgroup="/system.slice" cpu="cpu1"
> 
> This is a *total* bikeshed, but (so feel free to ignore), what about
> something more akin to;
>     inst [0 or "/::cpu0"] labels [cgroup="/" cpu="cpu0"] value 7137875587296
>     inst [1 or "/::cpu1"] labels [cgroup="/" cpu="cpu1"] value 3539695017434
> ?

Heh, yep - just as long as its script-parsable (I had it the other way so
that awk/sed/perl/python/friends could just grab from "labels" to EOL ...
*shrug*, either is fine.

> [...]
> For the additions to the pmUnits struct;
> Do we want to use an int for the labelsAll case? or could we perhaps
> stick that in the pmLabels* structs so we have more flexibility in the
> pmUnits struct later?  What are you evnisioning happening if we set
> these flags (including the labelsAll bit), and then a 'dynamic' relabel
> happens.  Will that flag (labelsAll) specify a 'read only' style label
> which forbids modification?

labelsSet is the only really required flag.  labelsAll I'm in two minds
about ... its just a space optimisation & if theres dynamic change to
certain labels such that its not valid, it should not be set in the
first place I guess.

> > - These labels.d files would be name=value (basename,= file contents)
> > pairs,
> > under sysadmin control (i.e. likely updated via
> > puppet/chef/ansible/... etc).
> >
> > - We'll need rules around valid name and value characters (probably similar
> > to PMNS naming conventions; no whitespace, limited special characters, etc,
> > for the label names at least).
> 
> So, I was looking into some of the documentation for the syslog plugin
> for logstash, and it also seems to specify an array type of label we
> might want to support (which we'd need to pay attention to in the
> overwrite/append situation above).

Hmm.  Maybe a name="comma,separated,value,list" could support that concept?

cheers.

--
Nathan

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