pcp
[Top] [All Lists]

Re: [pcp] My first PMDA, some questions..

To: Jan-Frode Myklebust <janfrode@xxxxxxxxx>
Subject: Re: [pcp] My first PMDA, some questions..
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 17 Nov 2014 01:29:27 -0500 (EST)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20141116200958.GA8464@xxxxxxxxxxxxxxxxx>
References: <20141116200958.GA8464@xxxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: CcRWSbswWHqdEMLBztIw86+mzEUVCw==
Thread-topic: My first PMDA, some questions..
Hi Jan-Frode,

----- Original Message -----
> I'm writing my first python pmda to collect 143 global + numthreads*13
> metrics from the Unbound recursive DNS server. A sample of the metrics:

Great, welcome!

> [...]
> I have a simple python pmda running that sets up and populates the
> total.num metrics, and that works fine, but I don't see how I'm
> supposed to handle the dynamic numthreads metrics. Any pointers? What I
> have now are simple:

There are two options:
- using an instance domain to represent the dynamic nature of the threads
(see add_indom() in pmdagluster for a python example)
- using dynamic metrics (all python metrics are actually dynamic, but see
below for current restrictions).

>         self.values['total.num.queries'] = 0
>         self.add_metric(name + '.total.num.queries', pmdaMetric(
>                 self.pmid(0, 0),
>                 c_api.PM_TYPE_U64, c_api.PM_INDOM_NULL, c_api.PM_SEM_COUNTER,
>                 pmUnits(0, 0, 1, 0, 0, c_api.PM_COUNT_ONE)),
>         'Total number of queries from all threads.')
> 
> 
> How would I add the "threadX.num.queries" when I don't know how many
> threads I will have?

At what point do you know how many threads you have?  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.

There is an effort nearing completion to allow metrics to be registered at
any point after PMDA.run() too, via the python API - this will be merged
shortly [http://www.pcp.io/pipermail/pcp/2014-November/005969.html] but is
not in place for you right now.

> Also, I'm wondering how often the fetch() procedure in the pmda is called,
> and if there's any way of controlling that. I don't know how advicable it
> will be to be calling the external command for generating all stats every
> second..
> What's triggering the fetch()? Is it me running "pmval -t 1
> total.num.queries",

(yep)

> or will it always be collecting at a given intervall?

(no)

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.

If you have concerns about running the command frequently, one option is to
cache the results for a short time, and respond with the cached results if
fetches come in too quickly for the PMDA to comfortably handle.  Chapter 2
of the Programmers Guide (http://www.pcp.io/doc/pcp-programmers-guide.pdf)
has a section "2.2.4 - Caching PMDA" with a more details.

cheers.

--
Nathan

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