PMFIND_CHECK(1)

πŸ“¦
version 7.2.2 Β· 3 versions
, in arch rolling, centos-stream 10, centos-stream 9, debian trixie, fedora 43, fedora 44, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– PMFIND_CHECK β€” the girlies' guide to pmfind_check πŸ’–

okay so bestie, this is the manual page for pmfind_check (that's the section 1 one, General Commands Manual, in case you were wondering which of the twelve billion pmfind_check pages you landed on πŸŽ€). Sit down, grab a strawberry drink, and let's talk about auto-discovering PCP collector hosts like it's the most iconic thing that's ever happened. Because honestly? It is. πŸ’…


✨ NAME ✨

pmfind_check β€” administration of Performance Co-Pilot discovery. That's the whole vibe. She administrates. She discovers. She's booked and busy. πŸ‘‘


🌸 SYNOPSIS 🌸

$PCP_BINADM_DIR/pmfind_check [-CNV?]  [-l logfile]

look at her. short. punchy. main character energy. ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

so this is a shell script, right, and her whole job is to glue the Performance Co-Pilot collector service discovery mechanisms (peep PCPIntro(1) if you don't know her πŸ’œ) together with pmie(1) and pmlogger(1) service administration. Which means: multiple collector hosts can be monitored from one single centralized host. one. centralized. host. the way that is so efficient of her 😭

important bestie, don't skip this: the pmfind service is tightly integrated with the pmie and pmlogger services. So those have to be enabled too, if you want the services started for every collector system that pmfind discovers. they're a package deal. a trio. no splitting them up. πŸ™ˆ

pmfind_check is designed to be enabled via a service management daemon like systemd(1) on Linux. She gets run from a system timer β€” either by systemd or by cron on other systems. Once per timer interval, pmfind goes off and attempts discovery of PCP collector systems. And for each unique system she finds, pmfind_check creates pmie_check and pmlogger_check control file entries, so that those latter processes can manage one pmie and one pmlogger service for each discovered collector system. one per host. organized. slay. πŸ’…

When you run her through systemd, these processes get launched immediately, because systemd is literally watching the service control files for changes. nosy queen, love her. πŸ‘€ And with systemd you can also kick off an immediate service discovery with pmfind and pmfind_check by modifying the $PCP_SYSCONF_DIR/pmfind directory in any way. any. way. touch a file, she's awake. ⚑

When you run her from cron instead, the next (also timer-based) invocation of pmie_check or pmlogger_check will start and manage the associated pmie and pmlogger processes. a lil delayed, but she gets there. 🐒✨

Now β€” the control file entries that pmfind_check creates follow the convention of individual files for each collector host. They're named using the (unique) source identifier that pmfind calculates. And that identifier? It's a hash calculated based on (non-optional) context labels available from every collector host, and it's the same source identifier reported and used by pminfo(1) and pmseries(1). consistency!! we love a shared identifier, fr fr 🫢


πŸ‘‘ OPTIONS πŸ‘‘

The available command line options are:

  • -C, --containers β€” this one makes pmfind_check query each discovered collector system for running containers as well, and those containers will then be individually monitored. yes, individually. every little container gets her attention. πŸ“
  • -l file, --logfile=file β€” so, to make sure mail doesn't get unintentionally sent when these scripts run from cron(8), diagnostics always go to log files. By default that file is $PCP_LOG_DIR/pmfind/pmfind_check.log, but you can change it with the -l option. And here's the lil detail: if this log file already exists when the script starts, it gets renamed with a .prev suffix (which overwrites any log file saved earlier 😭 rip old logs) before diagnostics are generated to the new log file.
  • -N, --showme β€” this enables a show me'' mode, where the programs' actions are **echoed but not executed**, in the style of make -n''. Using -N together with -V maximizes the diagnostic capabilities for debugging. the ultimate combo, iykyk πŸ”₯
  • -V, --verbose β€” the output from the cron execution of the scripts may be extended using -V, which enables verbose tracing of their activity. By default the scripts generate no output unless some error or warning condition is encountered. (silent until something goes wrong β€” very mysterious of her πŸ’€) Using -N in conjunction with -V maximizes the diagnostic capabilities for debugging.
  • -?, --help β€” display usage message and exit. the classic. the icon. 🌈

πŸŽ€ CONFIGURATION πŸŽ€

The command line options passed to pmie and pmlogger can be customized via the $PCP_SYSCONFIG_DIR/pmfind configuration file. customization era ✨

Refer to the pmie_check and pmlogger_check manual pages for details of the control file format generated by pmfind_check. (she doesn't write the format, she just feeds it, bestie πŸ’œ)

By default, each collector system's pmie logfile will be created in $PCP_LOG_DIR/pmie/source and pmlogger archives will be created below $PCP_ARCHIVE_DIR/source. This is consistent with the way pmie(1) and pmlogger(1) maintain their activity logs and archive files. consistency again!! she's nothing if not consistent. πŸ¦‹

Typical crontab(5) entries for periodic execution of pmfind_check are given in $PCP_SYSCONF_DIR/pmfind/crontab (unless it's installed by default in /etc/cron.d already) and shown below.

# every minute, discover remote PCP services
*       *       *       *       *       $PCP_BINADM_DIR/pmfind_check

every. single. minute. she's committed. 😀

When using systemd(1) on Linux, no crontab entries are needed, because the timer and path mechanisms provided by systemd are used instead. different platform, different strategy, same queen. πŸ’…


🌈 FILES 🌈

  • $PCP_PMIECONTROL_PATH.d β€” PCP inference engine control files for each discovered metric source, typically one per host or container.
Warning: the files herein must not be writable by any user other than root. fr fr, keep them locked down. πŸ”’
  • $PCP_PMLOGGERCONTROL_PATH.d β€” PCP logger control files for each discovered metric source, typically one per host or container.
Warning: the files herein must not be writable by any user other than root. same rule, same energy. πŸ”’
  • $PCP_SYSCONFIG_DIR/pmfind β€” default pmie and pmlogger command line arguments, and other parameters passed to pmfind.
  • $PCP_SYSCONF_DIR/pmfind/crontab β€” sample crontab for automated script execution by root β€” exists only if the platform does not support the /etc/cron.d mechanism. conditional queen. πŸŽ€

πŸ’œ 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. And the $PCP_CONF variable may be used to specify an alternative configuration file, as described in pcp.conf(5). so if you wanna point her somewhere else, that's your ticket. 🎟️


⭐ SEE ALSO ⭐

PCPIntro(1), pmcd(1), pmfind(1), pmie(1), pmie_check(1), pminfo(1), pmlogger(1), pmlogger_check(1), pmseries(1), systemd(1), crontab(5), and cron(8).

the whole friend group. go read them all, bestie, they're all connected 🫢✨


and that's the page!! brought to you by Performance Co-Pilot (that's the PCP crew πŸ’–) β€” this is the PMFIND_CHECK(1) page, section 1, General Commands Manual. mwah, go discover some collectors, ily πŸŽ€πŸ’…βœ¨

πŸ“¦ where this page comes from