Hi Jan-Frode,
----- Original Message -----
> On Mon, Nov 17, 2014 at 01:29:27AM -0500, Nathan Scott wrote:
> >
> > At what point do you know how many threads you have?
>
> After "unbound" is started, and I guess it might change if someone
> changes the unbound configuration. But should in general be pretty
> static..
>
>
> > If you can find out
> > before the call to PMDA.run(), then you can just add them like any other
> > metric (with the first parameter to add_metric() being "thread%d.xxx". If
> > you can only find out after the call to run(), then the current python API
> > will not work for you.
>
> Ok, hmm... not sure which option I'll go for.
>
I'd recommend choosing instances, looks like they'd suit well here
from what I've seen so far and they're simpler to work with.
> >
> > The client (monitor) tools drive the fetch interval, PMDAs just respond
> > with
> > the latest values - they typically have no knowledge of the sampling rate.
> > There can also be multiple clients, sampling at different (unrelated)
> > times.
>
> So two people running "pmval metric" will by default trigger 2 fetches
> per second??
Yes. For some PMDAs thats a walk in the park (we have folks sampling
the kernel, mmv, proc, etc PMDAs many times per second, just from one
client). These rates can be readily achieved with no measurable load,
for those PMDAs.
> Or will they be smart enough to share one? 1 fetch per
> second should be OK, but much more is getting scary..
OK - its up to the PMDA to cap this if it feels it's appropriate for
the domain its extracting data from.
> > the Programmers Guide (http://www.pcp.io/doc/pcp-programmers-guide.pdf)
> > has a section "2.2.4 - Caching PMDA" with a more details.
> > [...]
>
> BTW: Here's my first shot -> https://github.com/janfrode/unbound-pmda
> based on the gluster pmda.
>
Good stuff. Is this a PMDA you would like to include in PCP, or do you
want to maintain/release it separately? (its your choice of course)
One thing I noticed is this PMDA would greatly benefit from a python
version of pmda_pmid_name() from the perl API. This converts a PMID
(well - just the cluser,item pair) into a metric name using the data
structures that the language binding maintains.
So In your fetch callback, you'd call that first and it gives back the
string metric name. This'd remove the need for that long if/elseif/
elseif/..etc. you have there.
But, noone has implemented a python version of that API yet - would you
be interested in hacking on that? (see the data structures maintained
by PMDA.add_metric() in src/python/pcp/pmda.py, if so)
cheers.
--
Nathan
|