The first time a pmid appears in a pmFetch, pmlogger calls pmNameAll to
get all of the names of the metric from the pmns to build the pmns
fragment in the archive ... at this point the only name that can be
found for pmid 2.4.1 is pmcd.agent.status, because the other "name" is
not really in the pmns that is available to pmcd, and is not even
"owned" by the PMDA with domain 2.
I don't see a simple way to prevent this happening ...
Changing the name->pmid mapping using dynamic pmns entries that cross
PMDA boundaries is probably not a great idea in this case ... sigh.
Of course you could use a derived metric to recover from the first
problem, but that's probably throwing good money after bad.
On Thu, 2010-04-22 at 13:30 +1000, nathans@xxxxxxxxxx wrote:
> Hi Ken,
>
> Just came across an issue when using the "magic-dynamic-namespace
> name:pmid-auto-remapper-thanks-max" logic. This is quite critical
> for us, so I gotta get to the bottom of this one pronto - insight
> of any kind would be much appreciated.
>
> The problem can be seen as follows (obviously, in our case its our
> production PMDAs and not pmdasample) ...
>
> $ pminfo -m sample.secret.foo.bar.max.redirect pmcd.agent.status
> sample.secret.foo.bar.max.redirect PMID: 2.4.1
> pmcd.agent.status PMID: 2.4.1
> $ cat config
> log advisory on 1sec {
> sample.secret.foo.bar.max.redirect
> }
> $ pmlogger -c config -s 10 foo
> $ pminfo -a foo
> pmcd.agent.status
> pmcd.pmlogger.archive
> pmcd.pmlogger.port
> pmcd.pmlogger.host
>
> I'm quite surprised that the name stored is "pmcd.agent.status", when
> I asked for a sample metric. Its not clear how this is happening but
> its a real problem (think: scripts that were working would no longer,
> as soon as this moves from QA to production ... which fortunately it
> has not yet).
>
> Any clues as to how pmlogger is managing this impressive act? It must
> be doing a reverse PMID to name lookup somewhere? (can we avoid that,
> somehow?!?)
>
> Many thanks!
>
|