pcp
[Top] [All Lists]

odd side-benefit from dynamic pmns changes

To: pcp@xxxxxxxxxxx
Subject: odd side-benefit from dynamic pmns changes
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 04 Aug 2009 12:45:42 +1000
Reply-to: kenj@xxxxxxxxxxxxxxxx
The dynamic pmns stuff is quite a bit trickier than I originally
postulated (why, in retrospect, is that not a surprise?).

Any way I have it working for the DSO PMDA case (daemon case is a
straightforward, if tedious, extension).

Max Matveev observed yesterday that he'd like to be able to have one
PMDA use the dynamic PMNS features to return a PMID within its own
domain sometime, but at other times (depending on some global
configuration set up) have the same metric name translated into a PMID
that belongs to another PMDA.

This is (a) odd, and (b) even more amazing that he has a legitimate need
for this!

Well, after a short discussion, we postulated that it should "just
work" (tm) ... so I tried it.

$  pminfo -m | grep 2.4.1
pmcd.agent.status PMID: 2.4.1
sampledso.secret.foo.bar.max.redirect PMID: 2.4.1

sampledso.secret is a subtree of dynamic metric names known only to the
sample PMDA, but sampledso.secret.foo.bar.max.redirect maps to the PMID
of a metric exported from the pmcd PMDA.

So, ...
$ pminfo -f sampledso.secret.foo.bar.max.redirect

sampledso.secret.foo.bar.max.redirect
    inst [2 or "pmcd"] value 0
    inst [10 or "trace"] value 0
    inst [15 or "sendmail"] value 0
    inst [29 or "sample"] value 0
    inst [30 or "sampledso"] value 0
    inst [60 or "linux"] value 0
    inst [250 or "trivial"] value 4
    inst [253 or "simple"] value 0

8^)>

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