[ClusterLabs] Possible idea for 2.0.0: renaming the Pacemaker daemons
abeekhof at redhat.com
Wed Mar 28 18:32:41 EDT 2018
On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <
jgdr at dalibo.com> wrote:
> On Wed, 28 Mar 2018 15:50:26 -0500
> Ken Gaillot <kgaillot at redhat.com> wrote:
> > > > pacemakerd: PREFIX-launchd, PREFIX-launcher
> > >
> > > pacemakerd, alone, sounds perfectly fine to me.
> > Agreed -- but the argument against it is to allow something like "grep
> > pcmk /var/log/messages" to get everything.
> Then I would pick PREFIX-master... But then I would hate having a
> process :(
> Maybe all the logging information should be handled by one process so
> syslog/journald/stderr are happy?
> Despite it's multiprocess architecture, PostgreSQL either:
> * emit to syslog/journald using the same ident for all process
> * capture stderr of all process and redirect to one file.
> > > > cib: PREFIX-configd, PREFIX-state
> > >
> > > Tricky...It deals with both config and state...
> > >
> > > By the way, why in the first place the CIB messages must be in the
> > > log file?
> > > Filling logs with XML diffs resulting from other actions already
> > > logged earlier
> > > sounds like duplicated informations.
> > They are kept out of the syslog, which is where most users are expected
> > to look. They are in the detail log, which is for more advanced
> > troubleshooting.
> oh ok, sorry.
> I just finished a day reading log file /var/log/pacemaker.log on a Suse 12
> that was packed with XML diffs :/
> Maybe I should have checked /var/log/messages or the syslog setup...
> But honestly, I hate having mixed logs all packed in one same files
> like /var/log/messages :/
Theres a very good reason for it though - the relative timing of events is
the only way to establish cause and effect.
Though by now there is surely a decent library for logging to files with
sub-second timestamps - if we could incorporate that into libqb and have
corosync use it too... then we could consider 1 log per daemon.
In which case, the outcome of the PREFIX-SUFFIX discussion above could
instead be used for /var/log/pacemaker/SUFFIX
> > The detail log messages are useful mainly because CIB changes can come
> > from external sources, not just cluster daemons,
> Sure, but a simple info messages explaining that «the CIB has been updated
> tool "<tool_here>" » sound enough to me.
to you, because you know what you changed.
anyone else reading the logs (ie. people doing support) hasn't got a clue
and knowing who changed what is crucial to understanding what the cluster
did and why
> > and also to easily see the XML syntax was as expected.
> And this can go to detail/debug logs I suppose.
> Users mailing list: Users at clusterlabs.org
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users