----- Original Message -----
> On 01/07/13 01:18, Frank Ch. Eigler wrote:
> >...
> > If it were not too much work, I'd rather see generated files distinct
> > from hand-made files. Perhaps pmlogger et al. could run pmcpp on its
> > configuration file (and let the generated one be #include'd), or
> > search a directory and consume the union of the files there.
>
> This would appear to pass the "not too much work" pre-condition. The
> only issues that I can see are ...
> 1. pmlogger config file syntax does not include a version header (unlike
> some of the other config files we define and use), so we'd need to
> invent one going forward, or add some keyword glue at the start of the file
> 2. pmlogger config files use sh-like commenting, so comment lines
> beginning with # are not going to work all that well with pmcpp (or any
> other cpp look alike) ... we'll probably need some sed | pmcpp | sed
> logic to make this transparent
Another issue that just occurred to me...
3. The [access] section needs to appear at the end of the final file.
> If we do 2., then 1. may not be required ... always preprocess and
> existing config files are unchanged.
>
> > 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.
> > Basically, auto-configured network-wide logging on designated central
> > hosts.
>
> This is a great idea.
*nod*, vigorously.
> I have one immediate application where this would be most useful in load
> balanced cloud-land where the servers comes and go as load dictates.
This could have saved plenty of effort in previous deployments I've been
involved with - removes lots of otherwise manual administrator effort to
configure things. Even for puppet-driven sites, there's still effort to
manage initial setup correctly, then maintain that puppet config state
going forward.
cheers.
--
Nathan
|