----- Original Message -----
> Thank you Nathan for all the advices!
No problem!
> I'm currently rewriting the PMDA but I still have some questions. I've
> been to the IRC channel but if I understand correctly most of you are
> in Australia so it's hard to communicate (I'm in France).
Its a mixed bag, but yes timezones are not friendly for you & I - the
guys who helped you out the other day are in Canada (fche) and Germany
(ddiss), and there's other folks scattered around the globe. If you
can stay logged on I'll get back to you overnight, if you prefer IRC.
>
> a) When I ./Install my PMDA, I now get:
>
> Check cifs metrics have appeared ... 21 warnings, 42 metrics and 21
> values
>
> But the /var/log/pcp/pmcd/cifs.log file only has 1 warning line. Where
> can I see thoses 21 warnings?
The Install process does a final verification step using "pminfo -v cifs"
- thats where these warnings will be
> It may come from the values (same number?) but the log file just has:
>
> [Thu Aug 29 15:44:58] pmdacifs(9785) Warning: cannot find the user
> pcp to switch to
Ah, what version of PCP are you using, which platform, and how did you
install it? A "pcp" account should have been created on your system
as part of the installation process (by rpm, deb, mac PackageManager).
If working in the source tree with no local install, this will need to
be manually setup (or, set PCP_USER in your pcp.conf, and ensure the
PMDA uses that).
In your cifs PMDA, there is a line "set_user('pcp')" or something like
that? - thats the bit that drops root privileges and runs the process
as a regular user.
> b) About hash-based indoms: the _key_ of the hash is the label on the
> instance, but what is the _value_ for? I've looked at the PMDA.xs file
> and it seems to be a user pointer to anything, and serve no specific
> purpose. If that's the case, how do I know which instance is which in
> fetch_callback() when I get an instance number as an argument?
Its entirely up to you how you use that - you can choose not to use it
at all if its not helpful, but usually its handy to store a pointer to
a data structure there - in your case, it might be a hash reference to
a hash containing all the values for metrics for each individual mount
point. Then, in the fetch callback you can use
my $hashref = pmda_inst_lookup($mount_indom, $inst);
with the $inst passed in, and you'd have the values for that specific
mount point. The pmda_pmid_name($cluster, $item) routine might be of
use in your case as well, where the metric name contains part of your
hash key (iirc).
For some examples - src/pmdas/simple/pmdasimple.perl has an example of
using pmda_inst_lookup(), and src/pmdas/kvm/pmdakvm.pl is quite a good
example of pmda_pmid_name() use.
Oh, one other unrelated thing I forgot to mention the other day - we
were talking about the different smb1 / smb2 kernel ops vectors, and
metric differences as a result. NFS has a similar sort of issue, in
that case the namespace is used to encode different versions. IOW,
nfs.* nfs3.* nfs4.* are used - you might want cifs.smb1.* cifs.smb2.*
(alongside your other version-independent cifs metrics).
cheers.
--
Nathan
|