----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> I guess pmlogconf escaped at some point after the initial open source
> PCP release ... it certainly is in something of a "state".
>
> I'd be willing (happy is probably a bit over the top) to take on some
> remediation in this area.
Awesome, thanks!
> The largest issue I see here is that the host where pmlogconf is run
> may or may not be the host where the pmcd that pmlogger will connect to
Yes, it should definately not be assuming that its generating a config
for the local host.
> is
> to be run, and even worse the metrics available on the local host and
> the host where pmlogger gets its metrics from may be very different.
>
> So it is not even clear what metrics should be in the external
> configuration file(s).
I think the external files should contain logical groups of metrics, like
"core linux kernel", "core windows kernel", "sqlserver", "mysql", "nfs
server", "samba server", ... etc, etc. Then we can probe for features
(presence / values of metrics is what we use here) and enable/disable as
needed. Both the configuration files and the probing mechanism should be
extensible (so a layered distro, like infiniband/pcp-cluster, or us here
at Aconex, can add both standard configs and service probes as needed).
> We almost need a command line option to specify something about the
> platform where pmcd will be running, like
> - a generic platform, e.g. Irix, Linux, Windows, Solaris, MacOSX
> and/or
It should figure this kind of thing out on the fly (kernel.uname.sysname,
etc) I think.
> - -h hostname (and then use a Larry Wall style algorithm to deduce
> that hostname smells like, er, Linux)
>
> Now one could see how this might work for an initial invocation to set
> up the skeleton. What is less clear is what happens subsequently, e.g.
> imagine foo.bar.mumble is in the control file, but is not present on the
> pmcd host when pmlogconf is run first. Later on, after an O/S upgrade
> or PMDA install, foo.bar.mumble is available on the pmcd host. What
> is the desired behaviour?
In our production environment, we run the probing and configuration file
generation from cron every few minutes to make sure we're logging what
we should be logging (IIRC, we actually tie this into pmlc to figure out
whether the control file loggers are running with the right config, and
restart loggers if need be - can't afford to let a whole day run by and
only on daily restart pick up changes to the configs).
> It may take a bit of discussion before we finalize the specs for what
> pmlogconf should really do.
*nod*. I think there's alot of scope for improving the management of
pmlogger farms here... would be great to have this functional and also
extensible for everyone, out-of-the-box, with minimal input (just the
set of hostnames, ideally).
cheers.
--
Nathan
|