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,
but it's kind of handy client-side, i.e. they work on existing archives and
on downrev live pmcds, etc.
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
work too well since pmLoadDerivedConfig is normally called before any contexts
have been created - I suppose the probe could be excecuted at the same time
the derived config is actually set up in __dminit(), and the config either
created or rejected depending on the probe. Context is available by the
time __dminit() is run).
But, I don't really see any sensible way around it - we need 'em for the
archive case, and there's no server-side derived metric concept either,
by design IIRC (too complex to do in pmcd I'm sure).
yep
If this is deemed reasonable, then my next commit
makes pmchart load all configs in this directory by default (and other
generic monitoring tools such as pmrep, pmval, pmdumptext etc could do
the same).
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
then __dminit() will reject it. That gives us platform independence and
also handles the case where an archive doesn't contain the required metrics.
TODO: deb packaging. By default this ships in the 'pcp' package for RPM
based distros.
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).
Cheers
-- Mark
|