> ----- Original Message -----
> > On 01/07/13 01:18, Frank Ch. Eigler wrote:
> > > ...
> > > The idea is small:
>
> But the implications are huge! :)
>
> > > - to have running pmcd's announce themselves on the
> > > local net via DNS-SD = avahi = zeroconf
> > > - to have pmlogger or pmlogconf or whatnot tool monitor the DNS-SD
> > > announcements, and create/shutdown new pmlogger instances for them.
>
> (and likewise for pmie)
>
> The "... or ... or ..." bit warrants some further discussion - I'll send
> some follow-up mail a little later with my thoughts/opinions there.
OK, wanted to get my thoughts out there on implementing this...
AIUI, we need something running all the time (daemon) that is able to catch
these Avahi events as they happen, indicating a pmcd has been detected on
the network that is available for logging (or inference).
Above we have "pmlogger or pmlogconf or whatnot" suggested - I think it has
to be the latter (whatnot). With the current model, pmlogger is designed to
record an archive for one host only - this requires something to start/stop
logging arbitrary hosts as they come/go on the network. pmlogconf today is
not a daemon, its more of a take-input-templates-+-produce-output-pmlogger-
config-for-one-host kind of deal. From experience, this works well, and it
isolates the pmloggers from each other so that they can be independently
controlled (as the remote host pmcd comes/goes).
So, I think we need something new (or change the status quo, but I suspect
that's a very big change and there will be significant reluctance there).
What I think we should do is as follows:
- introduce a new daemon, perhaps named pmlogger_server(1), that is able to
be run all the time on hosts that an admin wants to house all the archives
for remote host recording (e.g. puppet would install this rpm on just the
hosts designated as pcp archive stores).
- this daemon just listens for the Avahi pmcd events, and reacts to them
by updating the pmlogger_check/pmlogger_daily control file. On receipt of
a new-pmcd-host message, it would run pmlogconf(1) directed toward that
host, and generate a suitable pmlogger config (perhaps "config.hostname"
as Aconex do), and also add an entry to the pmlogger control file. Then,
invoke pmlogger_check(1) which will start a logger for that host.
- personally, I'd like a single /etc/pcp/pmlogger/control file to manage
both the local logger and remote ones. This could be done using the same
"# Do not modify from here onward" kind of concept in the control file,
as is done with the individual pmlogconf-generated pmlogger config files.
This'll support both separate control file (outside of /etc) if needed, as
well as those of us (like me) who want the simpler one-file-is-fine-thanks
strategy. The -c option to pmlogger_check can be used to request that an
alternate control file be used, in the former strategy, but the default
strategy should Just Work - pmlogger start script should start/stop all of
these loggers, IOW).
- this is a daemon, so an init script will be required, chkconfig support,
etc, etc. Importantly, it needs to be optional, since there may be only
one or two hosts on a network designated as remote-monitor servers.
- for packaging systems that support this, the daemon should probably live
in a separate package (rpm/deb) that is optionally installable on these
designated monitor hosts. so pcp-pmlogger-server.{rpm,deb}, perhaps.
Rinse, repeat - all of the above for pmie_server(1). All the same reasons
apply - separate daemon, separate package (its entirely possible people
will want only auto-logging or only auto-inferring, and not both, so I'd
suggest we not try to combine these daemons into one).
cheers.
--
Nathan
|