| PMDA(3pm) | User Contributed Perl Documentation | PMDA(3pm) |
PCP::PMDA - Perl extension for Performance Metrics Domain Agents
use PCP::PMDA;
$pmda = PCP::PMDA->new('myname', $MYDOMAIN);
$pmda->connect_pmcd;
$pmda->add_metric($pmid, $type, $indom, $sem, $units, 'name', '', '');
$pmda->add_indom($indom, [0 => 'white', 1 => 'black', ...], '', '');
$pmda->set_fetch(\&fetch_method);
$pmda->set_refresh(\&refresh_method);
$pmda->set_instance(\&instance_method);
$pmda->set_fetch_callback(\&fetch_callback_method);
$pmda->set_store_callback(\&store_callback_method);
$pmda->set_user('pcp');
$pmda->run;
The PCP::PMDA Perl module contains the language bindings for building Performance Metric Domain Agents (PMDAs) using Perl. Each PMDA exports performance data for one specific domain, for example the operating system kernel, Cisco routers, a database, an application, etc.
The behaviour of the run method is different in the presence of either the PCP_PERL_PMNS or PCP_PERL_DOMAIN environment variables. These can be used to generate the namespace or domain number files, which are used as part of the PMDA installation process.
The advantage of explicitly calling connect_pmcd early in the life of the PMDA is that this reduces the risk of a fatal timeout during the credentials handshake, which may be an issue if the PMDA has considerable work to do, e.g. determining which metrics and instance domains are available, before calling run.
The instances of the instance domain are defined by insts which can be specified as either a list or a hash.
In list form, the contents of the list must provide consecutive pairs of identifier (a integer, unique across all instances in the instance domain) and external instance name (a string, must by unique up to the first space, if any, across all instances in the instance domain). For example:
@colours = [0 => 'red', 1 => 'green', 2 => 'blue'];
In hash form, the external instance identifier (string) is used as the hash key. An arbitrary value can be stored along with the key (this value is often used as a convenient place to hold the latest value for each metric instance, for example).
%timeslices = ('sec' => 42, 'min' => \&min_func, 'hour' => '0');
The help and longhelp strings are interpreted as the one-line and expanded help text to be used for this instance domain as further described in pmLookupInDomText(3).
Refer also to the replace_indom() discussion below for further details about manipulating instance domains.
The metric's metadata is defined by type, indom, sem and units and these parameters are used to set up the pmDesc structure as described in pmLookupDesc(3).
The help and longhelp strings are interpreted as the one-line and expanded help text to be used for the metric as further described in pmLookupText(3).
The replacement mapping must be a hash if the instance domain was registered initially with add_indom() as a hash, otherwise it must be a list.
Refer to the earlier add_indom() discussion concerning these two different types of instance domains definitions.
The instance domain to be loaded is identified by index, previously registered using add_indom().
Refer to the earlier add_indom() discussion concerning the two different types of instance domains definitions - only hash-based instance domains are persisted.
The given command is run early in the life of the PMDA, and a pipe is formed between the PMDA and the command. Line-oriented output is assumed (else truncation will occur), and on receipt of each line of text on the pipe, the callback function will be called.
The optional data parameter can be used to specify extra data to pass into the callback routine.
The optional data parameter can be used to specify extra data to pass into the callback routine.
An opaque integer-sized identifier for the socket will be returned, which can later be used in calls to put_sock() as discussed below.
The optional data parameter can be used to specify extra data to pass into the callback routine.
This interface deals with the issue of the file being renamed (such as on daily log file rotation), and will attempt to automatically re-route information from the new log file if this occurs.
The optional data parameter can be used to specify extra data to pass into the callback routine.
Every performance metric exported from a PMDA must have a unique PMID.
Most of the PM_* macros from the PCP C headers are available.
For example the type of a metric's value may be directly specified as one of PM_TYPE_32, PM_TYPE_U32, PM_TYPE_64, PM_TYPE_U64, PM_TYPE_FLOAT, PM_TYPE_DOUBLE, PM_TYPE_STRING or PM_TYPE_NOSUPPORT.
Perl PMDAs do not follow the -D convention of other PCP applications for enabling run-time diagnostics and tracing. Rather the environment variable PCP_PERL_DEBUG needs to be set to a string value matching the syntax accepted for the option value for -D elsewhere, see pmSetDebug(3).
This requires a little trickery. The pmcd(1) configuration file (PCP_PMCDCONF_PATH from /etc/pcp.conf) needs hand editing. This is best demonstrated by example.
Replace this line
foo 242 pipe binary python /somepath/foo.py
with
foo 242 pipe binary python \
sh -c "PCP_PERL_DEBUG=pdu,fetch /usr/bin/python /somepath/foo.py"
perl(1) and PCPIntro(1).
The PCP mailing list pcp@groups.io can be used for questions about this module.
Further details can be found at https://pcp.io
The Performance Co-Pilot development team.
Copyright (C) 2014 Red Hat. Copyright (C) 2008-2010 Aconex. Copyright (C) 2004 Silicon Graphics, Inc.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2 (see the "COPYING" file in the PCP source tree for further details).
| 2024-04-01 | perl v5.38.2 |