Hi Nathan,
Thanks for the feedback.
You might want to hide the "/var/tmp/" part of that, as the
pathname will need to be different on different platforms.
PCP has a (C) API interface - pmGetConfig(3) - which uses
/etc/pcp.conf to determine the PCP_TMP_DIR location (which
can be changed at runtime and which differs for different
platforms, esp. Win32).
In fact, probably don't want to expose the path separator
there at all either, as Windows blazes its own trail there
too of course.
Yeah, this was really just an example. You just inject any file path you
like; I think I'll leave the 'find the right place to put it' logic
outside of this code: e.g. in our case, this would be just be done via
Spring configuration, reading something from the deployment-specific
properties file which varies between win32 and linux boxes anyway.
The "mmv" part of the path needs to match with the first
part of the metric name - if its "mmv", they'll all be mmv.
prefixed (and if its "aconex" or "viewer", they'll all be
similarly prefixed automatically by the PMDA)... so might
want to abstract that part out too and allow it to be set
in just one place?
OK, didn't realise this was the case. Might change this from being
new PcpMmvWriter(File output)
to
new PcpMmvWriter(File pcpTempDir, String agentName, String fileName)
and then build the full path internally from that to make the API more clear
// Automatically uses default int handler
bridge.addMetric(
MetricName.parse("sheep[baabaablack].bagsfull.count"), 3);
A metric specification like sheep.bagfsull.count[baabaablack]
would match up with the PCP tools like pmdumptext use, and may
make things a bit more consistent between each side of the
bridge? I'm assuming "baabaablack" is an instance name here,
or did I miss something there?
Yes, it's an instance name. The reason for the (slightly strange)
handling is that I'm trying to map a very simple log4j-like descriptor
string to instance domains, etc.
For example, using the C API you can tell the agent easily that
sheep.bagsfull.count[baabaablack]
and
sheep.bagsfull.haveany[baabaablack]
are two metrics with the same instance (or that
sheep.bagsfull.material[limpy]
is another instance in the same domain), because you pass the
domain/instance across to the API. This is all purely String-based, so I
need a way to know that they're the same domain just from parsing the
String.
So the Java side kind of 'cheats'... it's assuming that
sheep[baabaablack].bagsfull.count
and
sheep[limpy].bagsfull.haveany
refer to the same indom because the instance part is at the same 'level'
of the tree (i.e. 'sheep'). Likewise, it would grok that
sheep.bagsfull[wool].count
and
sheep.bagsfull[poo].count
are within the same indom but
sheep.colours[black].noise
is separate, because 'sheep.bagsfull' and 'sheep.colours' aren't the
same prefix.
It's a bit hacky but I think, in reality, this reflects the way
instances are probably most commonly used (metrics sharing the same
indom are probably logically 'grouped' under a certain branch of the
namespace -- in our case, think aconex.controllers).
I will probably expose an 'advanced' (non-string-based) API, where
people can interact more like the C library ('request' a new indom, add
instances to it, etc) but that will come later I think.
I'm open to an alternative notation for the string-based one that keeps
a more PCP-standard notation but indicates what part of the 'tree' it
lives in:
sheep*.bagsfull.count[limpy]
or something equally horrid. Really not sure though, can't think of a
good alternative off the top of my head.
Heh ... thats funny on so many levels.
I aim to please.
Cheers,
Paul
|