pcp
[Top] [All Lists]

Re: [pcp] nfsclient pmda

To: Martins Innus <minnus@xxxxxxxxxxx>
Subject: Re: [pcp] nfsclient pmda
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 11 Mar 2014 18:32:50 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx, Ben Myers <bpm@xxxxxxx>, Max Matveev <makc@xxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5318EEA3.8040806@xxxxxxxxxxx>
References: <52F3A564.4060007@xxxxxxxxxxx> <D2E9833E-1D7F-41F5-97C4-4438712E3BF2@xxxxxxxxxxx> <742242243.21951337.1391769716120.JavaMail.root@xxxxxxxxxx> <530D0904.2090804@xxxxxxxxxxx> <1661706871.16390260.1393364346293.JavaMail.zimbra@xxxxxxxxxx> <5314EA02.9060906@xxxxxxxxxxx> <1369468338.20153383.1393911292559.JavaMail.zimbra@xxxxxxxxxx> <5318EEA3.8040806@xxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 5lCSgmglujzIz29UlPKOk2mAe1+7ew==
Thread-topic: nfsclient pmda

----- Original Message -----
> > (die() is a fairly drastic measure to take BTW - that could be made
> > more robust perhaps)
> I was trying to think of another way to handle this.  If
> /proc/self/mountstats is busted, then something is likely very wrong
> with the system.  If we can't open a user supplied file, not sure what
> the fallback would be.

You're right, I don't think there's much we can do (we could treat it as
"No data available" - so empty instance domain), but indeed it is a more
serious issue that requires radical intervention.  If it ever did happen
it would be good to have a logged timestamp with the message, if you want
that you can use $pmda->err(...) to get it.

> 
> I don't see qa/972 in the 3.9.0 src, and don't see that variable in any
> qa test.  Is it in a newer tree?

Its in the "dev" branch of the git tree, git://oss.sgi.com/pcp/pcp
[ http://oss.sgi.com/cgi-bin/gitweb.cgi?p=pcp/pcp.git;a=summary ]

> 
> Sorry, was a typo on my part. Meant
> 
> nfsclient.ops.getattr.count
> vs
> nfsclient.ops.count.getattr
> 
> 
> Just the ordering of the last 2 elements.  Max had a question on which
> would be more useful.  I have no opinion.
> 

Ah - I don't have a strong opinion either way.  Perhaps the former
"reads" a little better, to me anyway, but I think either would be
fine.

> -Should options.vers be a float or string since the values could be 3,
> 4, 4.1?

I would recommend using a string, that is what is done in other places for
version numbers anyway.  Sometimes separate metrics are presented for the
major & minor version parts, but that approach is pretty uncommon.

> -How much validation should be done in the regexes?  One of 2 remaining
> TODO's is a ipv6 regex which would be quite long.  Do we even care, or
> should I just take whatever is on the right side of the "="?

Not sure, but by default I would vote for simplicity - the latter option
sounds the simplest.

> -Other TODO is if we should look for deprecated options?  I found one
> (intr), but I'm sure there are more.

I wouldn't worry about it, up to you though.

> -Finally, this is only tested on linux (CentOS 6.4).  I have no access
> to Solaris, IRIX, *BSD, etc.  Not sure how this maps to them.

There is no /proc/self/mountinfo on those other platforms AFAIK, so just
testing on Linux sounds fine.

cheers.

--
Nathan

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