pcp
[Top] [All Lists]

Re: [pcp] [PATCH 0/6] nfsclient pmda

To: Max Matveev <makc@xxxxxxxxx>, Ben Myers <bpm@xxxxxxx>
Subject: Re: [pcp] [PATCH 0/6] nfsclient pmda
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 19 Oct 2011 06:25:33 +1100 (EST)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <20125.26224.261450.109478@xxxxxxxxxxxx>

----- Original Message -----
> On Mon, 17 Oct 2011 13:38:38 -0500, Ben Myers wrote:
> 
> bpm> Here is an nfs client pmda that reports statistics from
> bpm> /proc/self/mountstats. It is a work in progress but it has
> already
> bpm> been rotting for a little while so I'd like to get it out there.
> I've
> bpm> found it to be useful such as it is. Maybe you will too.
> 
> Just shows that if you wait long enough someone will do your job for
> you - I was thinking about adding these metrics to Linux PMDA but
> got lazy doing string parsing in C. Perl is easier for working with
> strings but it lacks pmdaCache support. Or did I miss it?

No, you didn't miss it, the PCP::PMDA instance domain support is
pretty basic fare & could use extension for pmdaCache routines.

> - U32 for counts is probably a bit low - any particular reason for
> not going U64?

What type is it in the kernel?  (need to match - there's also helper
pmda_long and pmda_ulong types if thats what the kernel is using)

> PS. Nathan, what's the point of splitting stuff in src/cpan into a
> separate package and at the same time shipping perl pmdas in the main
> one?

It allows separation of build dependencies for layered builds.  There's
a logical hierarchy of libpcp/libpcp_pmda -> PCP::PMDA -> pcp and anyone
building their own PMDAs outside of PCP doesn't need to install pcp for
their builds.

cheers.

-- 
Nathan

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