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

Hey,

I think overall this makes sense, a couple of thoughts inline.

"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).

[...]
> $ 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
?

[...]
> Some design notes
> =================
> - See attached pmapi.h patch for proposed client-side PMAPI extension,
>   regarding calling conventions for client tools needing access to
> labels.

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?

> - Context labels ("global") could be setup via /etc/pcp/pmcd/labels.d entries
> which are then exported via a pmcd.labels metric.  This would provide support
> for both archive and host context labelling, and would be wrapped up via the
> pmGetContextLabels(3) API.

Like you mention later, we should make sure to define the order of
preference with labels, not just what resolves first, but if it's an
overwrite or appending to the existing label.

> - 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).

Cheers,

Lukas

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