PMPROBE(1)

okay bestie, sit DOWN, because we're doing pmprobe from the General Commands Manual (section 1, obviously) and she is genuinely one of the most useful little gremlins in the whole PCP friend group 🫢


🌸 NAME 🌸

pmprobe β€” lightweight probe for performance metrics πŸ’…


✨ SYNOPSIS ✨

pmprobe [-dfFiILvVz?]  [-a archive] [-b batchsize] [--container=name]
[-D debug] [--derived=file] [-h hostname] [-K spec] [-n pmnsfile] [-O
time] [-Z timezone] [metricname ...]

πŸ’– DESCRIPTION πŸ’–

so like. pmprobe figures out whether performance metrics are even available, you know? the ones exported through the facilities of the Performance Co-Pilot (PCP). vibe check on your metrics, basically.

the metrics you care about are the ones you name in the metricname arguments. and here's the tea: if a metricname is a non-leaf node in the Performance Metrics Name Space (PMNS(5)), then pmprobe will recursively descend the PMNS and report on all the leaf nodes under it. so it's giving "you asked about the whole tree, bestie, here's every leaf." if you give it no metricname argument at all, it just uses the root of the namespace. starting from the very top, main character energy πŸ‘‘

this whole recursive-expansion thing can be inhibited by the -F (go faster) option β€” which cuts down the number of roundtrips to pmcd(1) when you already know your metricname arguments are leaf nodes ahead of time. iykyk 🌟

the output format is spartan and intended for use in wrapper scripts that build configuration files for other PCP tools. no frills, no filler, just facts. by default there's one line of output per metric, with the metric name followed by a count of the number of available values. error conditions get encoded as a negative value count (as per the PMAPI(3) protocols, but they may be decoded using pmerr(1)) and then followed by a textual description of the error. so if you see a negative number, that's not a typo, that's a situation 😭

unless you point it at another host with the -h option, pmprobe contacts the Performance Metrics Collector Daemon (PMCD) on the local host. keeping it local, periodt.

the -a option makes pmprobe use the specified set of archives instead of connecting to a PMCD.

the -L option makes pmprobe use a local context to collect metrics from PMDAs on the local host without PMCD. heads up though β€” only some metrics are available in this mode. not all of them get an invite to this party πŸ™ˆ

πŸ’€ -a, -h and -L are mutually exclusive. pick ONE. do not try to be greedy.

πŸŽ€ OPTIONS πŸŽ€

the available command line options are:

  • -a archive, --archive=archive β€” performance metric values are retrieved from the set of Performance Co-Pilot (PCP) archive files identified by the archive argument, which is a comma-separated list of names, each of which may be the base name of an archive or the name of a directory containing one or more archives. πŸ“‚
  • -b, --batch β€” this option may be used to define the maximum number of metrics to be fetched in a single request for the -v option and any pmLookupName(3) request that pmprobe calls with a list of leaf metric names. the default value for batchsize is 128. this is useful to avoid limitations on PDU request sizes and also to stagger fetches, which may otherwise timeout if pmcd(1) or a PMDA is slow to respond, particularly if a large number of metrics are being probed. so like, pacing yourself πŸ’…
  • --container=container β€” specify an individual container to be queried. πŸ«™
  • -d, --version β€” display version number and exit. bye! πŸ‘‹
  • --derived=dmfile β€” the dmfile argument specifies a file that contains derived metric definitions in the format described for pmLoadDerivedConfig(3). this option is a way to load derived metric definitions that's an alternative to the more generic use of the PCP_DERIVED_CONFIG environment variable as described in PCPIntro(1). and listen β€” using the --derived option and the PCP_DERIVED_CONFIG environment variable to specify the same configuration is a bad idea, so choose one or the other method. not both. i'm serious πŸ™…β€β™€οΈ
  • -f, --force β€” when used with -i or -I, the set of instances reported will be all of those known at the source of the performance data. by default the set of reported instances are those for which values are currently available, which may be smaller than the set reported with -f. so -f is the "show me everyone, even the quiet ones" flag ✨
  • -F, --faster β€” assume given metric names are PMNS leaf nodes. no recursion, just vibes at maximum speed πŸ”₯
  • -h host, --host=host β€” connect to pmcd(1) on host, rather than on the default localhost. 🌐
  • -i, --internal β€” report the internal identifiers for each instance. the values are in decimal and prefixed by ?. as a special case, the literal string PM_IN_NULL is reported for singular metrics. 🏷️
  • -I, --external β€” report the external identifiers for each instance. the literal string PM_IN_NULL is reported for singular metrics. 🏷️
  • -K spec, --spec-local=spec β€” when using the -L option to fetch metrics from a local context, this option controls 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. stack 'em πŸ‘‘
  • -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 pmprobe operates on the distributed Performance Metrics Name Space (PMNS), however, if the -n option is specified an alternative local PMNS file is loaded from the file pmnsfile. custom namespace era 🌈
  • -O time, --origin=time β€” when used in conjunction with an archive source of metrics and the options -f, the time argument defines a time origin at which the metrics should be fetched from the set of archives. refer to PCPIntro(1) for a complete description of this option, and the syntax for the time argument. ⏰
  • -v, --values β€” report the value for each instance, as per the formatting rules of pmPrintValue(3). when fetching from a set of archives, only those instances present in the first archive record for a metric will be displayed; see also the -O option. and heads up: -v is mutually exclusive with either the -I or -i options. 😀
  • -V, --verbose β€” this option provides a cryptic summary of the number of messages sent and received across the PMAPI interface. cryptic is literally the word they used, bestie πŸ•΅οΈβ€β™€οΈ
  • -z, --hostzone β€” change the reporting timezone to the local timezone at the host that is the source of the performance metrics, as identified via either the -h or -a options. 🌍
  • -Z timezone, --timezone=timezone β€” by default, pmprobe reports the time of day according to the local timezone on the system where pmprobe is run. the -Z option changes the timezone to timezone in the format of the environment variable TZ as described in environ(7). ⏳
  • -?, --help β€” display usage message and exit. πŸ†˜

πŸ¦‹ EXAMPLES πŸ¦‹

okay here's what it actually looks like, because honestly watching it run is the whole point:

$ pmprobe disk.dev
disk.dev.read 2
disk.dev.write 2
disk.dev.total 2
disk.dev.blkread 2
disk.dev.blkwrite 2
disk.dev.blktotal 2
disk.dev.active 2
disk.dev.response 2

see? one line per metric, name then count. clean ✨

$ pmprobe -I disk.dev.read disk.dev.write disk.all.total
disk.dev.read 2 "sda" "sdb"
disk.dev.write 2 "sda" "sdb"
disk.all.total 1 PM_IN_NULL

look at those external identifiers. and there's PM_IN_NULL doing its singular-metric thing 🫢

$ pmprobe -v pmcd.numagents pmcd.version pmcd.control.timeout
pmcd.numagents 1 9
pmcd.version 1 "5.0.0"
pmcd.control.timeout 1 5

-v said "and the VALUES too" and honestly she ate πŸ’…

$ pmprobe -v disk.dev.total disk.all.total
disk.dev.total -1012 Unknown metric name
disk.all.total 1 4992466

and THERE'S the negative value count with the error text right after it. -1012 is not a count, bestie, that's Unknown metric name in disguise 😭 (decode it with pmerr(1) if you want the full story)


🌸 FILES 🌸

  • $PCP_VAR_DIR/pmns/* β€” default PMNS specification files

πŸ’œ 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).

for environment variables affecting PCP tools, see pmGetOptions(3).


πŸ” DEBUGGING OPTIONS πŸ”

the -D or --debug option enables the output of additional diagnostics on stderr to help triage problems β€” although ngl, 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.

debugging options specific to pmprobe are as follows:

  • appl0 β€” batch information when -b used

⭐ SEE ALSO ⭐

PCPIntro(1), pmcd(1), pminfo(1), pmlogdump(1), PMAPI(3), pmErrStr(3), pmGetOptions(3), pmSpecLocalPMDA(3), pcp.conf(5), pcp.env(5) and PMNS(5).


and that's the whole page, bestie πŸŽ€ this one came to you from Performance Co-Pilot, version PCP, and the page itself is PMPROBE(1) β€” go forth and probe responsibly, ily, bye πŸ‘‘πŸ’–

πŸ“¦ where this page comes from