pcp
[Top] [All Lists]

Re: [pcp] PMDAs for lm_sensors, HDD SMART monitoringâ

To: David O'Shea <dcoshea@xxxxxxxxx>
Subject: Re: [pcp] PMDAs for lm_sensors, HDD SMART monitoringâ
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Mon, 4 Jan 2016 07:04:49 +1100
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <CAN0DjM0JnCe0RxMsEBVV2PEZsPLi4ROcpfikXyg1iNkPHBhd1g@xxxxxxxxxxxxxx>
References: <CAN0DjM1GGZJ2MOdDohbaf7WZ25j3g_7CxzfWxVvKH=a2pKcLAw@xxxxxxxxxxxxxx> <56833B81.2080605@xxxxxxxxxxxxxxxx> <CAN0DjM0JnCe0RxMsEBVV2PEZsPLi4ROcpfikXyg1iNkPHBhd1g@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
On 02/01/16 22:07, David O'Shea wrote:
...
Should I fork https://github.com/performancecopilot/pcp and file a pull
request to improve the samples to refer to cpmda.PMDA_FETCH_*?

That will work.  Or send patches in email.

I always err on the side of way too much detail in such diagrams, but in
this case I'm personally interested just in what needs to happen in my
PMDA.  Specifically, if a client is monitoring a few of my metrics, how
does that appear to the PMDA, since I want to run 'smartctl' just once.
However, that is a moot point now that I'm going to change the PMDA to
have a separate thread doing the polling.

Too much detail is probably not what you wanted here ... the call graph through libpcp and libpcp_pmda can get pretty complicated for a request that arrives at a PMDA (which might be delivered as a PDU for a daemon PMDA, or a procedure call for a DSO PMDA).

Let me think about this for a while ...

<Prev in Thread] Current Thread [Next in Thread>