----- Original Message -----
>
> nathans wrote:
>
> > [...]
> > For Linux hosts, crontab entries are automatically installed
> > for daily log rotation and checking (both pmlogger & pmie).
>
> Would you considering pushing a random snapshot of dev into fedora
> rawhide, so people can experiment with it easier? (We do this with
> systemtap, semiautomagically pushing updates weekly.)
Maybe - I'm away all of next week so I'm a bit hesitant to push any
possibly-half-baked stuff beyond the git tree dev branch. Further
testing this arvo has uncovered some other subtle problems too.
./Makepkgs makes this kind of full-package-install experimentation a
trivial matter of course, if one were so inclined. ;)
> > [...] There has also been some concern that having automatically-
> > modified/updated configuration files below /etc will cause heartache
> > for some sysadmins. [...] Discuss please - offer alternatives,
> > patches, discussion, ideas, etc, etc, and lets come up with
> > something great.
>
> If it were not too much work, I'd rather see generated files distinct
> from hand-made files.
Its more work, not sure about "too much". For me, it still feels a bit
like we would be obfuscating things a bit by housing the generated files
somewhere outside of the usual location. But if possible, my preference
is for both deployment scenarios to work.
> 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.
Realise I have not talked about this aspect much, and while pmcpp has
been suggested as a possible solution here, in practice it has shown
to be inflexible in certain situations.
So, we are talking about "should we use pmlogconf or cat-a-series-of-all-
possible-configuration-files, with no knowledge of the remote host setup,
and let pmlogger sort it out when it starts up" to manage our farm of
pmlogger instances (one per remote host that Avahi has kindly told us
about) which often need different configurations depending on the remote
host. This is because some are Windows (some of which have sqlserver),
some run Apache, some have MMV-instrumented applications to log, and so
on.
The fundamental problem is that remote hosts are often so different there
is no superset of configuration files we can install that will give the
right answer as to what should be logged. This is why pmlogconf came to
be (more history: http://comments.gmane.org/gmane.comp.sysutils.pcp/2909)
and its dynamic probing capabilities were defined based on experience in
the Aconex production environment at the time. The particular cases that
kept coming up IIRC were where certain metrics needed to be filtered out
based on the presence/absence of specific instances. These were things
like the presence of a named database instance, or a running application
instance, or something like that - the metrics were present but should
not be logged (sometimes) - so some dynamic decision-making capability
was needed.
Of course, pmlogconf gives a super-set of the cat-all-files-in-a-directory
functionality.
cheers.
--
Nathan
|