Ken McDonell wrote:
The dynamic pmns stuff is quite a bit trickier than I originally
postulated (why, in retrospect, is that not a surprise?).
so how did the pmID pad field out in the end?
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
Some uses I can think of that we've struggled with in the past:
1. deprecate a PMDA, but keep some of it's namespace in the replacement
2. conditional support for certain metrics, e.g. standard or
premium value-plus varieties
3. conditionally enabled metrics or instance domains e.g. via pmie rules, etc
4. alternative instance domains and/or semantics, e.g. redirect parts of
the standard namespace to the cluster PMDA
5. multiple domains in the one PMDA (urk)
I'm getting carried away a bit ...
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.
$ pminfo -f 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
pcp mailing list