PMSTORE(1)

πŸ’… PMSTORE(1) β€” from the General Commands Manual ✨

okay so bestie, buckle up: this page is PMSTORE(1), it lives in the General Commands Manual, and it's giving main character energy for everyone who's ever needed to just… change a metric's value. πŸŽ€

πŸ¦‹ NAME

pmstore β€” modify performance metric values 🫢

✨ SYNOPSIS

pmstore [-fFLV?] [-D debug] [-h host] [-i instances] [-K spec] [-n pmnsfile] metricname value

🌸 DESCRIPTION

So like, under certain circumstances it's genuinely useful to be able to modify the values of performance metrics β€” for example to re-initialize counters, or to assign new values to metrics that act as control variables. That's the whole vibe.

pmstore changes the current values for the nominated instances of a single</> performance metric, as identified by metricname and the list of instance identifiers following the -i argument. Heads up though: instances must be a single argument, with elements of the list separated by commas and/or white space. By default, all instances of metricname will be updated.

Normally pmstore operates on the default Performance Metrics Name Space (PMNS), see PMNS(5). But if the -n option is specified, an alternative namespace is loaded from the file pmnsfile. πŸ’–

Unless you direct it to another host with the -h option, pmstore will interact with the Performance Metric Collector Daemon (PMCD) on the local host.

The -L option causes pmstore to use a local context to store to metrics from PMDAs on the local host without PMCD. Only some metrics are available in this mode. And no cap: the -h and -L options are mutually exclusive. πŸ’€

The -f option forces the given value to be stored, even if there is no current value set.

The interpretation of value is dependent on the syntax used in its specification and the underlying data type of metricname, as follows. πŸ‘‘

  1. If the metric has an integer type, then value should be an optional leading hyphen, followed either by decimal digits or 0x and some hexadecimal digits. 0X is also acceptable in lieu of 0x. See strtol(3) and the related routines.
  2. If the metric has a floating point type, then value should be either in the form of an integer described above, or a fixed point number, or a number in scientific notation. See strtod(3).
  3. If the metric has a string type, then value is interpreted as a literal string of ASCII characters.
  4. If the metric has any other type (i.e. PM_TYPE_EVENT or PM_TYPE_AGGREGATE) then no encoding of value from the command line makes sense, and the values of these metrics cannot be modified with pmstore.

The output reports the old value and the new value for each updated instance of the requested metric. 🌈

When using the -L option to fetch metrics from a local context, the -K option may be used to control the DSO PMDAs that should be made accessible. The spec argument conforms to the syntax described in pmSpecLocalPMDA(3). More than one -K option may be used.

Normally pmstore will report the old value (as initially retrieved using pmFetch(3)) and the new value from the command line. The -F option forces another pmFetch(3) after the pmStore(3) and the returned value is reported as the new value. This is useful in cases where metricname is a metric that provides different semantics for the store operation, e.g. to increment the current value or reset a counter (independent of the value from the command line). πŸ”₯


πŸŽ€ OPTIONS

The available command line options are:

  • -f, --force β€” Store the value even if no current value set.
  • -F, --fetch β€” Report the metric value after setting it.
  • -i insts, --insts=insts β€” Restrict store to the comma-separated list of instances.
  • -h host, --host=host β€” Connect to pmcd(1) on host, rather than on the default localhost.
  • -K spec, --spec-local=spec β€” When fetching metrics from a local context (see -L), the -K option may be used to control the DSO PMDAs that should be made accessible. The spec argument conforms to the syntax described in pmSpecLocalPMDA(3). More than one -K option may be used.
  • -L, --local-PMDA β€” Use a local context to collect metrics from DSO PMDAs on the local host without PMCD. See also -K.
  • -n pmnsfile, --namespace=pmnsfile β€” Normally pmcd loads the default Performance Metrics Name Space (PMNS) from $PCP_VAR_DIR/pmns/root, however if the -n option is specified an alternative namespace is loaded from the file pmnsfile.
  • -V, --version β€” Display version number and exit.
  • -?, --help β€” Display usage message and exit.

😭 DIAGNOSTICS

Two messages indicate a mismatch between the internal data type for metricname and the value provided. 🚨

The value "???" is out of range for the data type (PM_TYPE_...)

The value "???" is incompatible with the data type (PM_TYPE_...)


🌈 PCP ENVIRONMENT

Environment variables with the prefix PCP_ are used to parameterize the file and directory names used by PCP. On each installation, the file /etc/pcp.conf contains the local values for these variables. The $PCP_CONF variable may be used to specify an alternative configuration file, as described in pcp.conf(5). 🧚


πŸ’œ DEBUGGING OPTIONS

The -D or --debug option enables the output of additional diagnostics on stderr to help triage problems, although the information is sometimes cryptic and primarily intended to provide guidance for developers rather than for end-users. debug is a comma separated list of debugging options; use pmdbg(1) with the -l option to obtain a list of the available debugging options and their meaning.

fr fr, that debug output is not for the faint of heart. it's giving "developer only, bestie, no gatekeeping but also no hand-holding". πŸ™ˆ

πŸ”₯ SEE ALSO

pmcd(1), pminfo(1), pmval(1), PMAPI(3), pmFetch(3), pmSpecLocalPMDA(3), pmStore(3), strtod(3), strtol(3) and PMNS(5).


and that's the whole page, slay πŸ’… this one came to you from Performance Co-Pilot, aka PCP β€” go off, read it again, and stay iconic. πŸ«Άβœ¨πŸ’–

πŸ“¦ where this page comes from