PMDAs for lm_sensors, HDD SMART monitoringâ

["David O'Shea" <dcoshea@xxxxxxxxx>]

Hi all,

I'm new to PCP and would like to be able to use it to capture sensor data from lm_sensors and HDD SMART data on my CentOS 7 system (running PCP 3.10.6, but it seems that nothing that would affect me has changed since that version).

I assume the existing lmsensors PMDA must be designed for some old pre-3.x version of the Linux kernel since it is looking in /proc/sys/dev/sensors/ whereas the sensor data is now under /sys/class/hwmon/. Also, it is hard-coded for some particular sensors, which are not the ones I happen to have. I'm thinking about doing a re-write in Python that dynamically creates the metrics based on the sensors that are available. Perhaps if it uses libsensors it will work with various versions of the kernel. Any comments on this?

As for HDD SMART, I managed to get a Python PMDA working which can collect a few metrics, but I have a lot of questions and comments (but I'll save some for later):

- When I use dbpmda's timer, it takes 500 milliseconds for a response to be returned, is that too long?

- http://www.pcp.io/books/PCP_PG/html/id5190481.html (pcp-programmers-guide Section 2.3.4.1 "Instance Identification") says "It is preferable, although not mandatory, for the association between and external instance name (string) and internal instance identifier (numeric) to be persistent." 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?

- I'm most interested in SMART attributes, e.g. reallocated sectors, temperatures. A drive might have around 20 of these, and for each attribute there are some values I'd be fairly interested in ("value", "worst", "threshold" and "raw value") and some that I'm not so interested in but that might be worth logging periodically just like you would for configuration ("flag", "type", "updated" ("always" vs. "offline") and "when failed"). If I exposed a metric for every one of those values, and a drive had 20 attributes, that'd be 20 * 8 = 160 metrics. Is there such a thing as exposing too many metrics?

- A further complication is that if I have two drives with different models, they might not have the same attributes. If they both have a "Temperature_Celsius", of course I'll treat that as a single metric that both instances have values for. 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 for creating metrics from attributes so users can choose to map them both to "Unknown_Attribute_16" or perhaps have model-specific attributes "Unknown_Attribute_16_WD..." and "Unknown_Attribute_16_HGST...". Does this sound reasonable?

- 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 */

 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.

- 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!

Thanks in advance,
David