1PMDA(3)                    Library Functions Manual                    PMDA(3)
2
3
4

NAME

6       PMDA - introduction to the Performance Metrics Domain Agent support li‐
7       brary
8

C SYNOPSIS

10       #include <pcp/pmapi.h>
11       #include <pcp/pmda.h>
12
13        ... assorted routines ...
14
15       cc ... -lpcp_pmda -lpcp
16

DESCRIPTION

18       To assist in the development of Performance Metric Domain  Agents  (PM‐
19       DAs) for the Performance Co-Pilot (PCP), a procedural interface is pro‐
20       vided that extends the Performance Metrics Application Programming  In‐
21       terface  (PMAPI(3)) library.  These procedures are designed to enable a
22       programmer to quickly build a PMDA which can then  be  tested  and  re‐
23       fined.   However, this also implies that a PMDA has a particular struc‐
24       ture which may not be suitable for all PMDA implementations.
25
26       Once you are familiar with the PCP and PMDA frameworks, you can quickly
27       implement  a  new  PMDA  with only a few data structures and functions.
28       This is covered in far greater detail in the Performance Co-Pilot  Pro‐
29       grammer's Guide.
30
31       A  PMDA  is  responsible for a set of performance metrics, in the sense
32       that it must respond to requests from  pmcd(1)  for  information  about
33       performance metrics, instance domains, and instantiated values.
34
35       This  man page contains sections of the simple PMDA which is located at
36       $PCP_PMDAS_DIR/simple.
37

COMMUNICATING WITH PMCD

39       Two approaches may be used for connecting a PMDA to a pmcd(1)  process.
40       A  Dynamic  Shared  Object  (DSO)  can  be  attached  by  pmcd(1) using
41       dlopen(3) when the pmcd(1) process is started.  A procedural  interface
42       referenced  through  a shared data structure is used to handle requests
43       from pmcd(1) to the PMDA .
44
45       The preferred approach is for a separate process (daemon)  to  communi‐
46       cate  with pmcd(1) using the Performance Data Units (PDU) Inter-Process
47       Communication (IPC) protocol.
48
49       All PMDAs are launched and controlled by the pmcd(1) process on the lo‐
50       cal  host.   The  requests from the clients are received by pmcd(1) and
51       forwarded to the appropriate PMDAs.  Responses, when required, are  re‐
52       turned through pmcd(1) to the clients.  The requests (PDUs) that may be
53       sent to  a  PMDA  from  pmcd(1)  are  PDU_FETCH,  PDU_PROFILE,  PDU_IN‐
54       STANCE_REQ, PDU_DESC_REQ, PDU_TEXT_REQ and PDU_RESULT.  If the PMDA im‐
55       plements any  dynamic  metrics  it  may  also  receive  PDU_PMNS_CHILD,
56       PDU_PMNS_IDS, PDU_PMNS_NAMES and PDU_PMNS_TRAVERSE PDUs.
57

DEFAULT CALLBACKS FOR HANDLING PDUs

59       To  allow  a  consistent framework, pmdaMain(3) can be used by a daemon
60       PMDA to handle the communication protocol using the same callbacks as a
61       DSO  PMDA.   The  structure  pmdaInterface is used to convey the common
62       procedural interface and state information that is used by pmcd(1)  and
63       a  PMDA.   This  state  information includes tables describing the sup‐
64       ported metrics and instance domains.
65
66       As most of the procedural interface is identical for  all  PMDAs,  they
67       are   provided   as  part  of  this  support  library  (pmdaProfile(3),
68       pmdaFetch(3),  pmdaInstance(3),  pmdaDesc(3),  pmdaText(3)  and  pmdaS‐
69       tore(3)).   However, these routines require access to the pmdaInterface
70       state information so it must be correctly  initialized  using  pmdaCon‐
71       nect(3),  pmdaDaemon(3),  pmdaOpenLog(3), pmdaDSO(3), pmdaGetOpt(3) and
72       pmdaInit(3).
73

INSTANCES AND INSTANCE DOMAINS

75       Three structures are declared in /usr/include/pcp/pmda.h which  provide
76       a  framework  for  declaring the metrics and instances supported by the
77       PMDA.
78
79       Every instance requires a unique integer identifier and a unique  name,
80       as defined by the structure pmdaInstid:
81
82            /*
83             * Instance description: index and name
84             */
85
86            typedef struct {
87                int         i_inst;        /* internal instance identifier */
88                char        *i_name;       /* external instance identifier */
89            } pmdaInstid;
90
91       An  instance  domain  requires its own unique identification (pmInDom),
92       the number of instances the domain represents, and a pointer to an  ar‐
93       ray of instance descriptions.  This is defined in the structure pmdaIn‐
94       dom:
95
96            /*
97             * Instance domain description: unique instance id,
98             * number of instances in this domain, and the list of
99             * instances (not null terminated).
100             */
101
102            typedef struct {
103                pmInDom     it_indom;       /* indom, filled in */
104                int         it_numinst;     /* number of instances */
105                pmdaInstid  *it_set;        /* instance identifiers */
106            } pmdaIndom;
107
108       The simple PMDA has one instance domain for simple.color with three in‐
109       stances  (red,  green  and blue), and a second instance domain for sim‐
110       ple.now with instances which can be specified at run-time.   These  in‐
111       stance domains are defined as:
112
113            static pmdaInstid _color[] = {
114                { 0, "red" }, { 1, "green" }, { 2, "blue" }
115            };
116            static pmdaInstid *_timenow = NULL;
117
118            static pmdaIndom indomtab[] = {
119            #define COLOR_INDOM 0
120                { COLOR_INDOM, 3, _color },
121            #define NOW_INDOM 1
122                { NOW_INDOM, 0, NULL },
123            };
124
125       The  preprocessor macros COLOR_INDOM and NOW_INDOM are used in the met‐
126       ric description table to identify the instance  domains  of  individual
127       metrics.   These  correspond to the serial value in the instance domain
128       pmInDom structure (the domain field is set by pmdaInit(3) at run-time).
129       The  serial  value  must  be unique for each instance domain within the
130       PMDA.
131
132       The indom table shown above which is usually passed to pmdaInit(3) does
133       not  need  to  be created if one wants to write one's own Fetch and In‐
134       stance functions.  See pmdaInit(3) for more details.
135

NAMESPACE

137       Every PMDA has its own unique namespace using  the  format  defined  in
138       PMNS(5).  In summary, the namespace matches the names of the metrics to
139       the unique identifier.  The simple  PMDA  defines  five  metrics:  sim‐
140       ple.numfetch,  simple.color, simple.time.user, simple.time.sys and sim‐
141       ple.now.  The namespace  for  these  metrics  is  defined  in  $PCP_PM‐
142       DAS_DIR/simple/pmns and is installed as:
143
144            simple {
145                numfetch    253:0:0
146                color       253:0:1
147                time
148                now         253:2:4
149            }
150
151            simple.time {
152                user        253:1:2
153                sys         253:1:3
154            }
155
156       The  domain  number  of 253 is obtained from $PCP_VAR_DIR/pmns/stdpmid.
157       New PMDAs should specify a unique domain number in this file,  and  ob‐
158       tain  the number during installation.  This allows the domain number to
159       change by modifying only the file $PCP_VAR_DIR/pmns/stdpmid.
160
161       The simple.time and simple.now metrics are defined in separate clusters
162       to the other metrics which allows a PMDA to support more than 1024 met‐
163       rics, as well as grouping similar  metrics  together.   Therefore,  the
164       item  numbers for a new cluster may be identical to the item numbers in
165       other clusters.  The simple PMDA continues to increment the  item  num‐
166       bers to permit direct mapping (see pmdaInit(3)).
167
168       The namespace file should be installed and removed with the agent using
169       pmnsadd(1) and pmnsdel(1).  See the later sections on INSTALLATION  and
170       REMOVAL.
171
172       A  simple ASCII namespace can be constructed by creating a file similar
173       to $PCP_PMDAS_DIR/simple/root:
174
175            /*
176             * fake "root" for validating the local PMNS subtree
177             */
178
179            #include "$PCP_VAR_DIR/pmns/stdpmid"
180
181            root { simple }
182
183            #include "pmns"
184
185
186       and can be referred to with the -n option in most PCP tools.
187

METRIC DESCRIPTIONS

189       Each metric requires a description (pmDesc), which contains its Perfor‐
190       mance  Metric  Identifier (PMID), data type specification, instance do‐
191       main, semantics and units (see pmLookupDesc(3)).  A handle is also pro‐
192       vided for application specific information in the pmdaMetric structure:
193
194            /*
195             * Metric description: handle for extending description,
196             * and the description.
197             */
198
199            typedef struct {
200                void*       m_user;         /* for users external use */
201                pmDesc      m_desc;         /* metric description */
202            } pmdaMetric;
203
204       The simple PMDA defines the metrics as:
205
206            static pmdaMetric metrictab[] = {
207            /* numfetch */
208                { (void *)0,
209                  { PMDA_PMID(0,0), PM_TYPE_U32, PM_INDOM_NULL, PM_SEM_INSTANT,
210                    { 0,0,0,0,0,0} }, },
211            /* color */
212                { (void *)0,
213                  { PMDA_PMID(0,1), PM_TYPE_32, COLOR_INDOM, PM_SEM_INSTANT,
214                    { 0,0,0,0,0,0} }, },
215            /* time.user */
216                { (void*)0,
217                  { PMDA_PMID(1,2), PM_TYPE_DOUBLE, PM_INDOM_NULL, PM_SEM_COUNTER,
218                      { 0, 1, 0, 0, PM_TIME_SEC, 0 } }, },
219            /* time.sys */
220                { (void*)0,
221                  { PMDA_PMID(1,3), PM_TYPE_DOUBLE, PM_INDOM_NULL, PM_SEM_COUNTER,
222                      { 0, 1, 0, 0, PM_TIME_SEC, 0 } }, },
223            /* now */
224                { NULL,
225                  { PMDA_PMID(2,4), PM_TYPE_U32, NOW_INDOM, PM_SEM_INSTANT,
226                    { 0,0,0,0,0,0 } }, },
227            };
228
229       The  macro  PMDA_PMID  (defined  in /usr/include/pcp/pmda.h) is used to
230       specify each metric's cluster and item fields of the  associated  pmID.
231       As  with  instance  domains,  the domain field is set by pmdaInit(3) at
232       run-time, however, the default domain is assumed to be defined  by  the
233       PMDA in the macro MYDOMAIN.
234
235       The  metric  table  shown  above which is usually passed to pmdaInit(3)
236       does not need to be created if one wants to write one's own  Fetch  and
237       Descriptor functions.  See pmdaInit(3) for more details.
238

DSO PMDA

240       A  PMDA  that  is  run  as  a  DSO is opened by pmcd(1) with dlopen(3).
241       pmcd(1) will call the PMDA's initialization function that is  specified
242       in  $PCP_PMCDCONF_PATH.  This function is passed a pointer to a pmdaIn‐
243       terface structure which must be completed.  Any callbacks which are not
244       the default PMDA support library callbacks must be specified in the pm‐
245       daInterface structure.
246
247       The simple PMDA uses its own store and fetch callback.   simple_fetch()
248       calls  pmdaFetch(3)  which  requires a callback to be set with pmdaSet‐
249       FetchCallBack(3) as can be seen in $PCP_PMDAS_DIR/simple/simple.c.
250
251       The flag _isDSO is used to determine if the PMDA is a daemon or  a  DSO
252       so  that  the  correct  initialization  routine,  pmdaDaemon(3)  or pm‐
253       daDSO(3), is called.
254

DAEMON PMDA

256       A PMDA that is run as a daemon  is  forked  and  executed  by  pmcd(1).
257       Therefore,  unlike  a DSO PMDA, the starting point for a daemon PMDA is
258       main().  The agent should parse the command line  arguments,  create  a
259       log  file  and  initialize some data structures that pmcd(1) would ini‐
260       tialize for a DSO agent.
261
262       The pmdaInterface structure must be completely defined  by  the  daemon
263       PMDA.   The function pmdaDaemon(3) can be called at the start of main()
264       to set most of these fields.  Command line parsing can be simplified by
265       using pmdaGetOpt(3), which is similar to getopt(2), but extracts a com‐
266       mon set of options into the pmdaInterface  structure.   stderr  can  be
267       mapped to a log file using pmdaOpenLog(3) to simplify debugging and er‐
268       ror messages.  The connection to pmcd(1)  can  be  made  with  pmdaCon‐
269       nect(3)  and  the  loop  which  handles the incoming PDUs, pmdaMain(3),
270       should be the last function called.   This  can  be  seen  in  $PCP_PM‐
271       DAS_DIR/simple/simple.c.
272
273       The simple_init() routine is common to an agent that can be run as both
274       a Daemon and DSO PMDA.
275

HELP TEXT

277       Each PMDA must be able to provide pmcd(1) with the help text  for  each
278       metric.  Most PMDAs use specially created files with indexes to support
279       efficient retrieval of the help text.  Tools are provided with  PCP  to
280       create the help text files of appropriate format. See newhelp(1).
281

INSTALLATION AND REMOVAL

283       A  series  of  shell  procedures  are defined in $PCP_SHARE_DIR/lib/pm‐
284       daproc.sh which greatly simplify the  installation  and  removal  of  a
285       PMDA.
286
287       The Install scripts for most PMDAs should only need to specify the name
288       of the PMDA in iam, call pmdaSetup which sets  up  some  default  vari‐
289       ables, checks permissions (you have to be ``root'' to install or remove
290       a PMDA), checks that you're in the right directory (somewhere that ends
291       with  /pmdas/$iam),  optionally  generate  the Performance Metrics Name
292       Space (PMNS) and PMDA domain number files for  Perl  or  Python  PMDAs,
293       checks the PMDA domain number is valid, etc., specify the communication
294       protocols, and finally call pmdaInstall to do all the work of  updating
295       the  PMNS,  updating  the pmcd(1) control file, notifying or restarting
296       pmcd(1),
297
298       Beyond pmdaSetup and pmdaInstall, another optional helper  routines  is
299       pmdaChooseConfigFile that may be used to interactively select or create
300       a PMDA-specific configuration file, e.g. pmdalogger(1).
301
302       The Remove scripts are even simpler as  setting  up  the  communication
303       protocols  are  not  required, so set the name of the PMDA in iam, then
304       call pmdaSetup followed by a call to pmdaRemove.
305
306       Further information is contained in the  $PCP_SHARE_DIR/lib/pmdaproc.sh
307       file and the following section.
308
309       Optionally,  a PMDA may provide an Upgrade script alongside Install and
310       Remove.  If present this script  will  be  used  by  the  pmcd  startup
311       process  to ensure corrections to an installation have been made before
312       starting the PMDA.  Examples of such corrections  include:  updates  to
313       pmcd.conf  when a PMDA script or binary has been renamed, when the PMDA
314       supports a new format of its configuration file, or if  there  is  some
315       latent problem from an earlier install (e.g. some PMDAs may need to in‐
316       troduce use of the notready keyword in pmcd.conf, as described below).
317

INSTALLATION REFINEMENTS

319       As outlined below there are a number of variables that can be set in  a
320       PMDA's  Install  script  to influence the behaviour of the installation
321       procedures.  These would typically need to be set before  the  call  to
322       pmdaInstall,  but  in  some instances (like $iam and the cases specifi‐
323       cally noted below), before the call to pmdaSetup.
324
325       The following variables control the communication options  between  the
326       PMDA  and pmcd(1).  At least one of $daemon_opt, $dso_opt, $perl_opt or
327       $python_opt must be set to define the supported mode(s)  of  communica‐
328       tion.   If  more  than one of these is set the user will be prompted to
329       make a selection when the Install script is run.
330
331       daemon_opt      We are willing to install the PMDA as a daemon.
332                       Default: true
333
334       dso_opt         We are willing to install the PMDA as a DSO, so pmcd(1)
335                       will  use  the  dynamic  linking  loader  to attach the
336                       PMDA's DSO at run-time and communication  from  pmcd(1)
337                       to  the  PMDA and back uses procedure calls, not an IPC
338                       channel.
339                       Default: false
340
341       dso_entry       For a DSO PMDA, this is the name of the PMDA's initial‐
342                       ization routine.
343                       Default: ${iam}_init
344
345       dso_name        For a DSO PMDA, this is the full pathanme of the PMDA's
346                       DSO file.
347                       Default: $PCP_PMDAS_DIR/$iam/pmda_$iam.$dso_suffix
348
349       pipe_opt        For a daemon PMDA, is the default  IPC  channel  via  a
350                       pipe(2)?
351                       Default: Platform-specific, so true for most, but false
352                       for Windows
353
354       perl_opt        We are willing to install the PMDA as a Perl script and
355                       pmcd(1)  will  use  the  perl(1) interpreter to run the
356                       PMDA.
357                       Default: false
358
359       pmda_dir        Full pathname to the directory where the PMDA's instal‐
360                       lation  files  (executable,  script,  PMNS source, help
361                       text source, etc) are to be found.
362                       Default: output from pwd(1)
363
364                       If set, must be done before the call to pmdaSetup.
365
366       pmda_name       For a daemon PMDA, this is the name of the PMDA's  exe‐
367                       cutable binary relative to the $pmda_dir directory.
368                       Default: pmda$iam
369
370       python_opt      We  are  willing to install the PMDA as a Python script
371                       and pmcd(1) will use the python(1) interpreter  to  run
372                       the PMDA.
373                       Default: false
374
375       ipc_prot        For  a daemon PMDA, this can be set to either binary or
376                       text.  The default is binary and text is  rarely  used.
377                       In  addition, an optional IPC parameter notready can be
378                       used to signify that the PMDA  will  start  up  in  the
379                       notready  state, e.g. ipc_prot="binary notready".  Note
380                       that the quotes are required.  The IPC parameters for a
381                       PMDA appear in pmcd.conf in the IPC Params column.  For
382                       further details, see pmcd(1) but  basically  pmcd  will
383                       not  issue  any  requests to a PMDA that has started in
384                       the notready state until the PMDA  sends  a  PM_ERR_PM‐
385                       DAREADY PDU.  This allows PMDAs with long startup times
386                       to initialize correctly without timing  out.   For  de‐
387                       tails,  see  pmdaSendError(3) and pmcd(1).  When a PMDA
388                       is in the notready state, any client requests  sent  to
389                       pmcd   for   the  PMDA  domain  will  return  with  the
390                       PM_ERR_PMDANOTREADY error.
391
392       socket_inet_def For a daemon PMDA using a socket(2) as the IPC  channel
393                       the  default  Internet  port number or service name (if
394                       known).
395                       Default: ""
396
397       socket_opt      For a daemon PMDA, is the default  IPC  channel  via  a
398                       socket(2)?
399                       Default: Platform-specific, so false for most, but true
400                       for Windows
401
402       The following variables control the PMNS options.
403
404       pmns_dupok      Most PMDAs do not have duplicate  names  for  the  same
405                       PMID  in  their  PMNS.   But  if  this is not the case,
406                       pmns_dupok should be set to true.
407                       Default: false
408
409       pmns_name       Each PMDA will add one or more non-leaf  nodes  to  the
410                       top  of  the PMNS.  The most common case is that all of
411                       the metrics for a PMDA will be placed  below  the  node
412                       named  $iam.   If  this is not the case, and especially
413                       when the PMDA adds more than one non-leaf node  at  the
414                       top  of the PMNS, pmns_name needs to be set to the list
415                       of node names (separated by white space), e.g. for  pm‐
416                       daproc(1) pmns_name is set to "proc cgroup hotproc".
417                       Default: $iam
418
419                       It is most important that if pmns_name is set to a non-
420                       default value in the Install script then it  must  also
421                       be set to the same value in the Remove script.
422
423       pmns_source     The  name  of the PMDA's PMNS source file.  By default,
424                       the name is interpreted as a relative pathname from the
425                       $pmda_dir directory.
426                       Default: pmns
427
428       The  following variables provide assorted additional options associated
429       with the installation of a PMDA.
430
431       args            Additional command line args for the PMDA.  These  will
432                       be  appended  to  the PMDA's control line in $PCP_PMCD‐
433                       CONF_PATH.
434                       Default: ""
435
436       check_delay     Delay (in seconds) after finishing the  PMDA  installa‐
437                       tion  (or  removal) before checking the availability of
438                       metrics from the PMDA.  May need to be increased if the
439                       PMDA has a lengthy startup procedure.
440                       Default: 0.3
441
442       signal_delay    Delay  (in seconds) after notifying pmcd(1) with a sig‐
443                       nal.  Required to allow pmcd(1) to complete  processing
444                       before  proceeding to the next step of the installation
445                       (or removal).
446                       Default: 1
447
448       configdir       Determines the directory in which a  PMDA's  configura‐
449                       tion file will be stored.  Used by pmdaChooseConfigFile
450                       so should be set before calling that procedure.
451                       Default: $PCP_VAR_DIR/config/$iam
452
453       configfile      Preferred configuration file for the PMDA.  Used by pm‐
454                       daChooseConfigFile so should be set before calling that
455                       procedure.
456                       Default: ""
457
458       default_configfile
459                       Default configuration file for the PMDA.  Used by pmda‐
460                       ChooseConfigFile  so  should be set before calling that
461                       procedure.
462                       Default: ""
463
464       dso_suffix      Standard suffix for a  DSO.   Should  not  need  to  be
465                       changed under normal circumstances.
466                       Default:  Platform-specific, so 'so' for Linux, 'dylib'
467                       for Mac OS X, 'dll' for Windows, etc.
468
469                       If set, must be done before the call to pmdaSetup.
470
471       help_source     The name of the help text source file  that  should  be
472                       used as input to pmnewhelp(1).  By default, the name is
473                       interpreted as a relative pathname from  the  $pmda_dir
474                       directory.
475                       Default: help
476
477       python_name     Full pathname of the Python script for a Python PMDA.
478                       Default:          $pmda_dir/pmda$iam.python          or
479                       $pmda_dir/pmda$iam.py
480
481       The shell procedures  in  $PCP_SHARE_DIR/lib/pmdaproc.sh  manipulate  a
482       number of temporary files using the variable $tmp as the prefix for the
483       name of the temporary files.  $tmp is a directory that is created, used
484       and  removed internally within the procedures of $PCP_SHARE_DIR/lib/pm‐
485       daproc.sh but can also be used as the prefix for temporary files needed
486       by  a  PMDA's  Install  or Remove scripts.  When used in this way, $tmp
487       should be followed by a ``/'' and then a suffix, e.g. $tmp/myfoo.   The
488       Install  and  Remove  scripts  should not use other temporary file name
489       prefixes nor use sh(1) trap statements to clean up temporary  files  as
490       this is all done within $PCP_SHARE_DIR/lib/pmdaproc.sh.
491

CAVEAT

493       Failing  to  complete  any of the data structures or calling any of the
494       library routines out of order may  cause  unexpected  behavior  in  the
495       PMDA.
496
497       Due  to changes to the PMAPI(3) and PMDA(3) API in the PCP 2.0 release,
498       as described in the product release notes, PMDAs built  using  PCP  2.0
499       must  specify  PMDA_INTERFACE_2 or later and link with libpcp_pmda.so.2
500       and libpcp.so.2.  Pre-existing Daemon PMDAs specifying  PMDA_PROTOCOL_1
501       will    continue   to   function   using   the   backwards   compatible
502       libpcp_pmda.so.1 and libpcp.so.1 libraries and may be recompiled  using
503       the headers installed in /usr/include/pcp1.x/ without any modification.
504       These backwards compatible headers and libraries are contained  in  the
505       pcp.sw.compat subsystem.
506

DIAGNOSTICS

508       Any PMDA which uses this library can set PMAPI(3) debugging control op‐
509       tion libpmda (with -Dlibpmda on the command line or via 3pmSetDebug(3))
510       to  to  enable the display of debugging information which may be useful
511       during development (see pmdbg(1)).
512
513       The status field of the pmdaInterface structure should  be  zero  after
514       pmdaDaemon,  pmdaDSO,  pmdaGetOpt, pmdaConnect and pmdaInit are called.
515       A value less than zero indicates that initialization has failed.
516
517       Some error messages that are common to most functions in  this  library
518       are:
519
520       PMDA interface version interface not supported
521                      Most  of  the  functions  require  that the comm.version
522                      field of the pmdaInterface structure be set to  PMDA_IN‐
523                      TERFACE_2  or  later.   PMDA_INTERFACE_2  or PMDA_INTER‐
524                      FACE_3 implies that the version.two fields are correctly
525                      initialized,  while  PMDA_INTERFACE_4  implies  that the
526                      version.four fields are correctly initialized  (see  pm‐
527                      daDaemon(3) and pmdaDSO(3)).
528

FILES

530       /usr/include/pcp/pmda.h
531                 Header file for the PMDA support library.
532
533       /usr/lib/libpcp_pmda.so
534                 Dynamic library containing PMDA support library routines.
535
536       $PCP_PMDAS_DIR/trivial
537                 The source of the trivial PMDA.
538
539       $PCP_PMDAS_DIR/simple
540                 The source of the simple PMDA.
541
542       $PCP_PMDAS_DIR/txmon
543                 The source of the txmon PMDA.
544
545       $PCP_PMCDCONF_PATH
546                 Configuration file for pmcd(1).
547
548       $PCP_VAR_DIR/pmns
549                 Location of namespace descriptions for every PMDA.
550
551       $PCP_VAR_DIR/pmns/stdpmid
552                 The unique domain identifiers for each PMDA.
553
554       $PCP_SHARE_DIR/lib/pmdaproc.sh
555                 Shell procedures for installing and removing a PMDA.
556

PCP ENVIRONMENT

558       Environment variables with the prefix PCP_ are used to parameterize the
559       file and directory names used by PCP.  On each installation,  the  file
560       /etc/pcp.conf  contains  the  local  values  for  these variables.  The
561       $PCP_CONF variable may be used to specify an alternative  configuration
562       file,  as  described in pcp.conf(5).  Values for these variables may be
563       obtained programmatically using the pmGetConfig(3) function.
564

SEE ALSO

566       dbpmda(1), newhelp(1), pmcd(1), pmnsadd(1), pmnsdel(1), PMAPI(3), PMWE‐
567       BAPI(3),   pmdaConnect(3),   pmdaDaemon(3),   pmdaDesc(3),  pmdaDSO(3),
568       pmdaFetch(3), pmdaGetOpt(3), pmdaInit(3), pmdaInstance(3), pmdaMain(3),
569       pmdaOpenLog(3),    pmdaProfile(3),   pmdaStore(3),   pmdaText(3),   pm‐
570       LookupDesc(3) and PMNS(5).
571
572       For a complete description of the pcp_pmda library and the PMDA  devel‐
573       opment process, refer to the Insight book Performance Co-Pilot Program‐
574       mer's Guide.
575
576
577
578Performance Co-Pilot                  PCP                              PMDA(3)
Impressum