On 03/09/2016 10:45 AM, Nathan Scott wrote:
----- Original Message -----
On 03/08/2016 11:14 AM, Nathan Scott wrote:
Hi Mark,
----- Original Message -----
RFC - ship a global derived metrics config directory in the pcp package.
$PCP_VAR_DIR/config/derived along with a config for IOSTAT metrics. Other
configs can be added.
My initial concern is: this is putting server-platform-specific stuff on
a client-side install - which is kinda going back to the bad old days of
agent Installs on client machines.
derived metrics are client-side. I guess we could add them to pmcd,
server-side,
Yep, understood; I was really just thinking out loud, not suggesting we go
do any of these things - lets work with what we've got for now & reassess
once we have more real-world experience with using it.
IOW, your example there (the iostat
metrics) is very Linux-specific.
the iostat example is fairly Linux specific. We could add some 'probe' syntax
to pmLoadDerivedConfig(3), like pmlogconf-setup, but that's not going to
*nod* - feels like overkill at this stage.
yes, it is overkill since pmLoadDerivedConfig already silently handles configs
that don't have the underlying metrics used as terms in the expression :
# cat foo.config
foo = disk.dev.read_foo + disk.dev.write_foo
bar = disk.dev.read + disk.dev.write
# PCP_DERIVED_CONFIG=foo.config pminfo -f foo bar
foo: pmLookupDesc: Unknown or illegal metric identifier
bar
inst [0 or "sda"] value 1331365
inst [2 or "sdb"] value 0
# PCP_DERIVED_CONFIG=foo.config pminfo -DDERIVE -f foo bar
pmRegisterDerived: register metric[0] event.flags = anon(PM_TYPE_U32)
pmRegisterDerived: register metric[1] event.missed = anon(PM_TYPE_U32)
Derived metric initialization from $PCP_DERIVED_CONFIG
pmLoadDerivedConfig("foo.config")
pmRegisterDerived: register metric[2] foo = disk.dev.read_foo +
disk.dev.write_foo
pmRegisterDerived: register metric[3] bar = disk.dev.read + disk.dev.write
__dmopencontext: bind metric[0] event.flags
__dmopencontext: bind metric[1] event.missed
__dmgetpmid: metric "foo" -> PMID 511.0.3
__dmgetpmid: metric "disk.dev.read_foo" -> Unknown metric name
bind_expr: error: derived metric foo: operand: disk.dev.read_foo: Unknown
metric name
__dmgetpmid: metric "bar" -> PMID 511.0.4
__dmopencontext: bind metric[3] bar
__dmgetpmid: metric "foo" -> PMID 511.0.3
__dmgetpmid: metric "bar" -> PMID 511.0.4
foo: pmLookupDesc: Unknown or illegal metric identifier
bar
inst [0 or "sda"] value 1331218
inst [2 or "sdb"] value 0
Sounds like a libpcp API will be needed here? Oh, or maybe not - we could
do this in the pmGetOptions code (maybe __pmEndOptions) and that will be
visible in all tools without changes then.
somewhere around there. Or actually, anywhere before contexts are created.
The easiest is just to putenv(PCP_DERIVED_CONFIG=...) if it's not already
defined, and __dminit() will pick it up in due course. If the probe fails
Yep, good call - so probably no API additions needed, which is good. Watch
out for QA fallout here, special QA handling for the event.* metrics ended up
splattered across the QA universe when we added those two metrics in.
So I'm proposing to add the above putenv call to __pmEndOptions() so that
global derived metrics will be loaded by default for all client tools (but
not overriding $PCP_DERIVED_CONFIG if it's already set). This is a libpcp
change, but not an API change.
Hmm, I wonder if thats the best place or should it be the pcp-conf package?
(for a pcp-libs -only install, which someone might do to support just their
own PMAPI utility)
yeah guess so. It's needed by all clients, and they require pcp-libs, which
in turn requires pcp-conf (at least in RPM spec, not sure about deb).
deb has a pcp-conf underlying everything too - see debian/pcp-conf.* files.
ok.
Regards
|