On 29/12/15 12:00, David O'Shea wrote:
Hi all,
G'day David and welcome.
Frank has already addressed a number of your questions, so treat this as
an addition to his response.
I assume the existing lmsensors PMDA must be designed for some old
pre-3.x version of the Linux kernel ..
I'd guess Linux 2.6 based on the available git history.
- When I use dbpmda's timer, it takes 500 milliseconds for a response to
be returned, is that too long?
It is getting on the long side ... pmcd's clients typically are willing
to wait $PMCD_REQUEST_TIMEOUT seconds (defaults to 10) but there are
other considerations for the PMDA developer that suggest being able to
respond to all the metrics in a single pmFetch() asap is desirable.
There is no hard limit, or even guidance here, but O(100) msec is
probably too long.
Since the data you're chasing here has relatively slow rates of change
(I presume), Frank's suggestion of a thread to periodically update the
metrics and a thread to respond to pmFetch() requests with the most
recently update values will probably work better. This template has
been used in existing PMDAs with long latency value instantiation times.
... Does this mean persistent while the PMDA
is running or persistent across restarts of the PMDA or the machine it
is running on? If it means persistent across restarts, does pmdaCache
help with that?
Absolutely across PMDA restarts. Highly desirable across reboots.
pmdaCache will help, and although it is a cache it can be persisted to
the local filesystem (one file per instance domain in
$PCP_VAR_DIR/config/pmda) so the cache is persistent up to loss of the
/var file system. See PMDA_CACHE_LOAD, PMDA_CACHE_SAVE and
PMDA_CACHE_SYNC in the pmdaCacheOp man page.
... Is there such a thing as exposing too many metrics?
No. Because the PCP protocols allow clients to cherry-pick the metrics
they are interested in, PMDAs typically support many metrics with the
the pattern of metrics being fetch varying from one environment or one
host to another.
The PMNS avoids metric name clashes, the instance names are defined per
PMDA, so the only issue would be additional overhead in the PMDA to
instantiate metrics that are not actually requested ... e.g. system
calls that return a struct full of data or in your case a thread that
might be instantiating recent values of metrics that are not requested,
and even in this case the code may be able to not instantiate values
until a request is received.
...However, if they both have an
"Unknown_Attribute" whose ID is say 16, it doesn't seem appropriate to
assume that that attribute means the same thing for both drives, so I
assume I should have a configuration file ...
As Frank has indicated, avoiding configuration files for PMDAs is good,
if possible. Decisions about metric availability and semantics are best
resolved in the PMDA, rather than leaving the client to deduce that A[1]
is not the same semantics as A[2].
A couple of things that might help:
- an instance domain can be the union of all the instances one might
expect, then specific metrics may have defined values for only a subset
of the instances, and that subset may differ from one metric to another
defined over the same instance domain
- dynamic metrics allow the PMDA to populate the PMNS on the fly after
some initial discovery at start up ... so you could have foo.bar.boring
and foo.bar.interesting on one machine, and only foo.bar.boring on
another machine
- In pmdasimple.python, simple_fetch_times_callback() for example
includes this code:
return [valuep.contents.value, 1]
return [c_api.PM_ERR_PMID, 0]
I assume the second element in the array - 0 or 1 in these examples -
corresponds to these definitions from pmda.h?
/*
* return values for a pmdaFetchCallBack method
*/
#define PMDA_FETCH_NOVALUES 0
#define PMDA_FETCH_STATIC 1
#define PMDA_FETCH_DYNAMIC 2 /* free avp->vp after __pmStuffValue */
Correct. This is documented in pmdaFetch(3) under PMDA_INTERFACE_5 (the
highest version of the interface supported by libpcp_pmda).
If so, it'd be nice if pmda.py defined those constants itself (or
possibly they could be extracted using something like SWIG but I have
never tried using that myself), as I struggled to work this out.
Looks like they are defined as I can see this code:
pmda_dict_add(dict, "PMDA_FETCH_NOVALUES", PMDA_FETCH_NOVALUES);
but it looks like none of the Python PMDAs in the source tree are using it.
- It would be nice if there was a sequence diagram (generated using e.g.
http://www.mcternan.me.uk/mscgen/ ) showing how PDUs being sent to the
PMDA get translated into various calls, and what order they are in. I
think I know how this works but I'm not totally sure yet!
OK. But "calls" in which context? ... at pmcd? at a client? at a PMDA?
|