Provided by: libpcp3-dev_4.0.1-1_amd64 bug

NAME

       pmLookupLabels,       pmGetInstancesLabels,      pmGetItemLabels,      pmGetClusterLabels,
       pmGetInDomLabels, pmGetDomainLabels, pmGetContextLabels - retrieve labels associated  with
       performance metric values

C SYNOPSIS

       #include <pcp/pmapi.h>

       int pmLookupLabels(pmID pmid, pmLabelSet **labelsets);

       int pmGetInstancesLabels(pmInDom indom, pmLabelSet **labelsets);
       int pmGetItemLabels(pmID pmid, pmLabelSet **labelsets);
       int pmGetClusterLabels(pmID pmid, pmLabelSet **labelsets);
       int pmGetInDomLabels(pmInDom indom, pmLabelSet **labelsets);
       int pmGetDomainLabels(int domain, pmLabelSet **labelsets);
       int pmGetContextLabels(pmLabelSet **labelsets);

       cc ... -lpcp

DESCRIPTION

       Labels  are  name:value pairs associated with performance metric values for the purpose of
       attaching additional metric metadata to values.  This  metadata  is  less  structured  and
       exists   separately  to  the  metric  descriptor  available  for  every  PCP  metric  from
       pmLookupDesc(3).

       Much like the metric descriptor metadata, labels are an integral part of the  identity  of
       each metric, and should rarely, if ever, change.

       The  pmLookupLabels  routine is a convenience interface providing retrieval for all labels
       associated with a single performance metric identifier, pmid.  It performs no  caching  of
       labels internally.

       For  efficiency  in  communication  and  storage within the various components of the PMCS
       (Performance Metrics Collection System), labels are maintained using a hierarchy.  The set
       of labels associated with any individual metric value consists of the union of labels from
       each of these sets of labels:

       1. Global labels (apply to all metric values from a host or archive context)

       pmGetContextLabels
               provides the labelset associated with all metric values from a given source (PMAPI
               context).

       2. Domain labels (apply to every metric within a PMDA)

       pmGetDomainLabels
               provides the labelset associated with the domain identifier.

       3. Instance Domain labels (apply to all metrics sharing that indom)

       pmGetInDomLabels
               provides the labelset associated with the instance domain identifier indom.

       4. Cluster labels (apply to a group of metrics within one domain)

       pmGetClusterLabels
               provides   the  labelset  associated  with  the  metric  cluster  (domain,cluster)
               identified by pmid.

       5. Item labels (apply to an individual performance metric)

       pmGetItemLabels
               provides the  labelset  associated  with  the  metric  item  (domain,cluster,item)
               identified by pmid.

       6. Instance labels (apply to individual instances of a metric)

       pmGetInstancesLabels
               provides the set of instance identifiers and labels in labelsets for each instance
               associated with the instance domain identifier indom.  The return value  indicates
               the number of elements in the result - one labelset for each instance.

       These  independent  labelsets can be merged using pmMergeLabelSets(3) to form the complete
       set of all labels associated with a given value.

LABEL SYNTAX

       Labels are stored and communicated within PCP  using  JSONB  format.   This  format  is  a
       restricted  form  of  JSON  suitable  for  indexing  and other operations.  In JSONB form,
       insignificant whitespace is discarded, and the order of  label  names  is  not  preserved.
       Within  the  PMCS  a  lexicographically  sorted  key  space is always maintained, however.
       Duplicate label names are not permitted.  The label with highest precedence  is  the  only
       one  presented.   If  duplicate  names are presented at the same hierarchy level, only one
       will be preserved (exactly which one wins is arbitrary, so do not rely on this).

       All name:value pair(s) present will be  converted  to  JSONB  form  and  merged  with  the
       existing  set  of  labels  for  the  requested  entity  (context, domain, indom, metric or
       instance).

       The label names are further constrained to the same set of rules defined for PMNS  subtree
       names.

       Each component in a label name must begin with an alphabetic character, and be followed by
       zero or more characters drawn from the alphabetics, the digits and the underscore  (``_'')
       character.  For alphabetic characters in a name, upper and lower case are distinguished.

       The  value  of  a  label  offers significantly more freedom, and may be any valid value as
       defined by the JSON  (http://json.org)  specification.   Redundant  whitespace  is  always
       removed within the PMCS.

PRECEDENCE

       The  complete set of labels associated with any metric value is built from several sources
       and duplicate label names may exist at any point in the source hierarchy.   However,  when
       evaluating  the label set (merging labels from the different sources) the JSONB concept of
       only presenting unique labels is used.  It is therefore  important  to  define  precedence
       rules in order that a deterministic set of uniquely named labels can be defined.

       As  a  rule  of  thumb,  the  labels  closest  to  PMNS  leaf nodes and metric values take
       precedence:

       1. Global context labels
           (as reported by the pmcd.labels metric) are the lowest precedence.

       2. Domain labels
           (for all metrics and instances from a PMDA) are the next highest precedence.

       3. Instance Domain labels
           associated with an InDom are the next highest precedence.

       4. Metric cluster labels
           associated with a PMID cluster are the next highest precedence.

       5. Metric item labels
           associated with an individual PMID are the next highest precedence.

       6. Instance labels
           associated with a metric instance identifier have highest precedence.

DATA STRUCTURES

       The primary output from pmLookupLabels is returned in the argument labelset as  an  array,
       using the following component data structures;

            struct {
                uint     name : 16;      /* label name offset in JSONB string */
                uint     namelen : 8;    /* length of name excluding the null */
                uint     flags : 8;      /* information about this label */
                uint     value : 16;     /* offset of the label value */
                uint     valuelen : 16;  /* length of value in bytes */
            } pmLabel;

            struct {
                uint     inst;           /* PM_IN_NULL or the instance ID */
                int      nlabels;        /* count of labels or error code */
                char     *json;          /* JSON formatted labels string */
                uint     jsonlen : 16;   /* JSON string length byte count */
                uint     padding : 16;   /* zero, reserved for future use */
                pmLabel  *labels;        /* indexing into the JSON string */
            } pmLabelSet;

       The  pmLabel provides information about an individual label.  This includes the offsets to
       the start of its name and value in the json  string  of  a  pmLabelSet,  their  respective
       lengths,  and  also  any  informative flags associated with the label (describing where it
       lies in the hierarchy of labels, and whether it is an intrinsic or extrinsic label).

       Building on this, the pmLabelSet provides information about the set of  labels  associated
       with  an  entity  (context,  domain, indom, metric cluster, item or instance).  The entity
       will be from any one level of the label hierarchy.   If  at  the  lowest  hierarchy  level
       (which  happens  to  be  highest precedence - PM_LABEL_INSTANCES) then the inst field will
       contain an actual instance identifier instead of PM_IN_NULL.

       The nlabels field describes the number of labels (name:value pairs) that can be  found  in
       both  the  accompanying json string (which is JSONB format - no unnecessary whitespace and
       with no duplicate label names) and  the  accompanying  labels  array  (which  has  nlabels
       elements).

EXAMPLES

       Consider  a  deployment  with  global  labels (assume $PCP_SYSCONF_DIR is set to its usual
       location of /etc/pcp) as follows:

       $ cat /etc/pcp/labels/*
       {
         "tier": "production",
         "datacenter": "hkg",
         "services": ["indexer","database"]
       }

       Use pminfo to form the merged labelsets for several pmdasample(1) metrics as follows:

       $ pminfo -m -f --labels sample.rapid sample.colour sample.mirage

       sample.rapid PMID: 30.0.64
            value 800000000
            labels {"agent":"sample","datacenter":"sydney","hostname":"acme.com","measure":"speed","role":"testing","services":["indexer","database"],"tier":"production","units":"metres per second","unitsystem":"SI"}

       sample.colour PMID: 30.0.5
            inst [0 or "red"] value 101
            inst [1 or "green"] value 202
            inst [2 or "blue"] value 303
            inst [0 or "red"] labels {"agent":"sample","datacenter":"syd","hostname":"acme.com","model":"RGB","role":"testing","services":["indexer","database"],"tier":"production"}
            inst [1 or "green"] labels {"agent":"sample","datacenter":"syd","hostname":"acme.com","model":"RGB","role":"testing","services":["indexer","database"],"tier":"production"}
            inst [2 or "blue"] labels {"agent":"sample","datacenter":"syd","hostname":"acme.com","model":"RGB","role":"testing","services":["indexer","database"],"tier":"production"}

       sample.mirage PMID: 29.0.37
            inst [0 or "m-00"] value 99
            inst [0 or "m-00"] labels {"agent":"sample","datacenter":"sydney","hostname":"acme.com","role":"testing","services":["indexer","database"],"tier":"production","transient":false}

       Here, pminfo has merged the separate  sets  of  labels  returned  from  pmGetContextLabels
       (names:  datacenter,  hostname,  services,  tier), pmGetDomainLabels (names: role, agent),
       pmGetInDomLabels  (names:  model),  pmGetItemLabels   (names:   units,   unitsystem)   and
       pmGetInstancesLabels (names: transient) to form the complete set for each of the metrics.

DIAGNOSTICS

       On  success  these  interfaces  all  return the number of elements in the labelsets array.
       associated with performance metrics.  The  memory  associated  with  labelsets  should  be
       released using pmFreeLabelSets(3) when no longer needed.

       Only  in  the case of pmLookupLabels will the resulting labelset be a merged set of labels
       from all hierarchy levels.

       For the other routines, except for pmGetInstancesLabels, if no labels exist at all for the
       requested  hierarchy  level  the  return  code  will  be  zero and no space will have been
       allocated.

       In the case of pmGetInstancesLabels, which can return multiple elements in  its  labelsets
       result  (one  set  of  labels  for  each  instance),  the nlabels field may be either zero
       indicating no labels for that instance, or a positive count of labels, or a negative PMAPI
       error code.

       Note  that  it is mandatory for a call to pmGetInstancesLabels to be preceded by a call to
       pmGetInDom(3) to ensure the instances have been resolved within the PMDA.

       If no result can be obtained, e.g. due to IPC failure using the current PMAPI context then
       pmGetInstancesLabels  will  return  a  negative  error  code  which  may be examined using
       pmErrStr(3).

SEE ALSO

       pmcd(1),   PMAPI(3),   pmFetch(3),   pmGetInDom(3),   pmLookupDesc(3),    pmLookupName(3),
       pmFreeLabelSets(3), pmMergeLabelSets(3) and pmNewContext(3).