Finally coming back to this thread, apologies for the lengthy delays.
----- Original Message -----
> ...
> How about a solution of complete segregation? IOW, let's keep the
> main pmlogger/pmie rc.d services for hand-made configurations as per
> the status quo ante.
Hmm, that isn't the status quo - pmieconf has been in pmie_check for
well over 10 years, and shipped enabled-by-default on IRIX for years.
pmlogconf has been around for many years too and the current version
was designed to fit into the rest of the logging scheme in backwardly
compatible ways, when the time came to enable logging by default. It
specifically deals with both the logger-farm requirement and the need
to change the configuration over time:
http://oss.sgi.com/pipermail/pcp/2010-June/001084.html
The current design is based on years of successful production logger
farm setup/use. So, I'm fairly confident the tools are both stable
and well-suited to the task such that we can switch 'em on by default
now, and get good results. Even if we move to a new betterer scheme
later, for now I have confidence in the existing mature tools, and I
definitely think we should stick with them.
That aside, the current dev branch code allows *both modes* - its not
an either-or choice for us here. The only times that pmlogconf would
be invoked is when a logger has been requested but we have no config
file for it, and when a pmlogconf-generated configuration file needs
updating based on new configuration snippets or changes to the logged
hosts metrics.
Thus, if this new-tool-that-responds-to-avahi-announced-nodes wants to,
it can specify its own configuration file (not generated via pmlogconf
if that is wanted) and the logger would be started up as one would
expect, and without pmlogconf being involved. The scripts contain a
number of safe-guards that prevent pmieconf/pmlogconf from being run
on any configuration files they did not originally generate.
So we can have our cake and eat it too. It will take some time to get
production-level confidence in any new scheme, in the interim we will
need to stick with the mature tools that we have.
> Instead, the new fully-automated configurations would be associated
> only with the omninymous pcp-server-monitor widget I'll be prototyping
> shortly, of which "local://" would be one default target (along with
> avahi-*). The pcp-server-monitor service would be the one that causes
> pure-default-pmlogconf of localhost (and optionally avahi-announced
> and named remote nodes).
Removing the "Instead", and that sounds fine. Indeed, both the simple
mode of using existing pmlogger check/daily scripts and any new scheme
must be able to interoperate (which is done already, since the current
scheme is effectively opt-in and the new scheme can override it).
cheers.
--
Nathan
|