PMDAFETCH(3)
β¨ PMDAFETCH β¨ β the PMDAFETCH(3) page, but make it cute
okay bestie, so this is PMDAFETCH(3) from the Library Functions Manual, and we are going to get through it together, no cap. it's giving "fill a pmResult structure with the requested metric values" energy and honestly? iconic. π
πΈ NAME πΈ
pmdaFetch, pmdaSetFetchCallBack β fill a pmResult structure with the requested metric values π«Ά
π C SYNOPSIS π
#include <pcp/pmapi.h>
#include <pcp/pmda.h>
int pmdaFetch(int numpmid, pmID *pmidlist, pmResult **resp,
pmdaExt *pmda);
void pmdaSetFetchCallBack(pmdaInterface *dispatch,
pmdaFetchCallBack callback);
cc ... -lpcp_pmda -lpcp
π¦ DESCRIPTION π¦
so pmdaFetch is a generic callback that a PMDA(3) uses to process a fetch request coming from pmcd(1). and where does that request come from? a client calling pmFetch(3). yes ma'am, the whole pipeline is giving main character energy. π
this is one of the few generic callbacks in libpcp_pmda (peep PMDA(3)) that is incomplete β it literally needs a further pmdaFetchCallBack method of its own. not me needing extra steps to function π. you register that additional callback with pmdaSetFetchCallBack, and the pmdaFetchCallBack method has this prototype:
int func(pmdaMetric *mdesc, unsigned int inst, pmAtomValue *avp)
pmdaFetch will allocate and resize the resp result structure, so it can store values for the numpmid metrics listed in pmidlist. slay, memory management. β¨
for each instance listed in the profile (see pmdaProfile(3)) of each metric listed in pmidlist, the pmdaFetchCallBack method gets called to fill the pmAtomValue structure identified by avp with a value for a specific metric-instance pair, identified by the metric descriptor mdesc and the instance inst. then that value gets copied into the pmResult structure. so many little handoffs, obsessed. π
the pmdaFetchCallBack method should return a value less than zero for an error, and the most likely cases would be:
PM_ERR_PMIDif the metric identified bymdescis not known to the methodPM_ERR_INSTif the method believes the instanceinstis not known for the metric identified bymdesc
the success error codes depend on which version of PMDA_INTERFACE the PMDA is using. buckle up. π
if the PMDA is using PMDA_INTERFACE_2 then on success the pmdaFetchCallBack method should return 0.
if the PMDA is using PMDA_INTERFACE_3 or PMDA_INTERFACE_4 then on success the pmdaFetchCallBack method should return 1 if a value is returned via avp, else 0 if no values are currently available for the requested metric-instance pair, although mdesc and inst both seem reasonable.
if the PMDA is using PMDA_INTERFACE_5 or later then on success the pmdaFetchCallBack method should return:
PMDA_FETCH_STATIC(1) if the value returned viaavpcan be ignored bypmdaFetchonce it has been copied into thepmResultstructure- else
PMDA_FETCH_DYNAMIC(2) if the value returned viaavpuses either thevporcpfields of thepmAtomValueand the associated value (buffer) was allocated using one ofmalloc(3),calloc(3),realloc(3),strdup (3)etc., andpmdaFetchshould release the memory by callingfree(3)once a new buffer has been allocated and the value copied - else
PMDA_FETCH_NOVALUES(0) if no values are currently available for the requested metric-instance pair, althoughmdescandinstboth seem reasonable
β οΈ bestie, listen. if thepmdaFetchCallBackmethod returns a value for an instance of a metric of typePM_TYPE_STRINGorPM_TYPE_AGGREGATE, some special care is needed: - the method should either use a static buffer, setavp->cporavp->vpto the address of the buffer and returnPMDA_FETCH_STATIC, - or use a dynamically allocated buffer, keep a static reference to the buffer's address, returnPMDA_FETCH_STATICandfree (3)orrealloc (3)or reuse the buffer the next time thepmdaFetchCallBackmethod is called, - else use a dynamically allocated buffer and returnPMDA_FETCH_DYNAMIC.
do NOT fumble this one, fr fr. π
π EXAMPLE π
the following code fragments are for a hypothetical PMDA that has metrics (A, B, C and D) and an instance domain (X) with two instances (X1 and X2). the instance domain and metrics description tables (see pmdaInit(3)) could be defined as:
static pmdaInstid _X[] = {
{ 0, "X1" }, { 1, "X2" }
};
static pmdaIndom indomtab[] = {
#define X_INDOM 0
{ 0, 2, _X },
};
static pmdaMetric metrictab[] = {
/* A */
{ (void *)0,
{ PMDA_PMID(0,0), PM_TYPE_32, PM_INDOM_NULL,
PM_SEM_INSTANT, {0,0,0,0,0,0} }, },
/* B */
{ (void *)0,
{ PMDA_PMID(0,1), PM_TYPE_DOUBLE, X_INDOM,
PM_SEM_INSTANT, {0,1,0,0,PM_TIME_SEC,0} }, },
/* C */
{ (void *)0,
{ PMDA_PMID(0,2), PM_TYPE_STRING, PM_INDOM_NULL,
PM_SEM_INSTANT, {0,0,0,0,0,0} }, },
/* D */
{ (void *)0,
{ PMDA_PMID(0,3), PM_TYPE_STRING, PM_INDOM_NULL,
PM_SEM_INSTANT, {0,0,0,0,0,0} }, },
};
a pmdaFetchCallBack method to be called from pmdaFetch could be defined as:
int
myFetchCallBack(pmdaMetric *mdesc, unsigned int inst, pmAtomValue *avp)
{
static char sbuf[20]; // reuse this buffer
char *dbuf; // malloc'd
switch (pmID_item(mdesc->m_desc.pmid)) {
case 0:
/* assign some value for metric A */;
avp->l = ...
break;
case 1:
switch (inst) {
case 0:
/* assign a value for metric B, instance X1 */;
avp->d = ...
break;
case 1:
/* assign a value for metric B, instance X2 */;
avp->d = ...
break;
default:
return PM_ERR_INST;
}
case 2:
/* place value for metric C in dbuf[] */
memcpy(dbuf, ...);
avp->cp = dbuf;
break;
case 3:
avp->cp = (char *)malloc(somesize);
/* place value in avp->cp */
pmsprintf(avp->cp, somesize, ...);
return PMDA_FETCH_DYNAMIC;
default:
return PM_ERR_PMID;
}
return PMDA_FETCH_STATIC;
}
π CAVEAT π
the PMDA must be using PMDA_INTERFACE_2 or later, as specified in the call to pmdaDSO(3) or pmdaDaemon(3). no exceptions bestie, this is not a vibe-optional situation. π¨
π₯ DIAGNOSTICS π₯
the following error messages indicate that there is a discrepancy between the namespace, pmdaMetric and pmdaIndom tables passed to pmdaInit(3), and the registered fetch callback:
pmdaFetch: Requested metric metric is not definedA requested metricmetricis not listed in thepmdaMetrictable. The namespace for thisPMDA(3)may contain additional metrics.pmdaFetch: PMID pmid not handled by fetch callbackThepmdaFetchCallBackmethod has returnedPM_ERR_PMID. This indicates that a metric may be listed in thepmdaMetrictable, but is not supported by the callback method.pmdaFetch: Instance inst of PMID pmid not handled by fetch callbackThepmdaFetchCallBackmethod has returnedPM_ERR_INST. This indicates that an instance of metric is listed in thepmdaIndomtable, but is not supported by the callback method.pmdaFetch: Fetch callback error:ThepmdaFetchCallBackmethod returned a result other thanPMDA_FETCH_NOVALUES,PMDA_FETCH_STATIC,PMDA_FETCH_DYNAMIC,PM_ERR_PMIDorPM_ERR_INST.pmdaFetch: Descriptor type (type) for metric pmid is badThe data typetypespecified for the metricpmidin thepmdaMetrictable is illegal.
and heads up: pmdaFetch will return -errno if an error occurred while allocating the pmResult structure or copying the value from the pmAtomValue. π
π SEE ALSO π
pmcd(1), PMAPI(3), PMDA(3), pmdaDaemon(3), pmdaDSO(3), pmdaInit(3) and pmFetch(3).
and that's the whole page bestie, you ate that. π
this has been Performance Co-Pilot β PCP β PMDAFETCH(3), mwah, go forth and fetch responsibly. ππ«Άπ
π¦ where this page comes from
- arch rolling: pcp 7.2.2-2 Β· GPL-2.0-or-later AND LGPL-2.1-or-later AND CC-BY-3.0
- centos-stream 10: pcp-doc 7.1.5-6.el10 Β· GPL-2.0-or-later AND CC-BY-3.0
- fedora 43: pcp-doc 7.0.1-1.fc43 Β· GPL-2.0-or-later AND CC-BY-3.0
- fedora 43: pcp-doc 7.2.1-1.fc43
- fedora 43: pcp-doc 7.2.2-1.fc43
- fedora 43: pcp-doc 7.2.2-2.fc43 Β· GPL-2.0-or-later AND CC-BY-3.0
- fedora 44: pcp-doc 7.1.0-6.fc44 Β· GPL-2.0-or-later AND CC-BY-3.0
- fedora 44: pcp-doc 7.2.1-1.fc44
- fedora 44: pcp-doc 7.2.2-1.fc44
- fedora 44: pcp-doc 7.2.2-2.fc44 Β· GPL-2.0-or-later AND CC-BY-3.0
- ubuntu resolute: libpcp-pmda3-dev 7.1.1-1
- ubuntu stonking: libpcp-pmda3-dev 7.2.1-2build1
- Copyright (c) 2000-2004 Silicon Graphics, Inc. All Rights Reserved
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms