Re: [ClusterLabs] Opinions wanted: another logfile question for Pacemaker 2.0

[Jehan-Guillaume de Rorthais]

On Mon, 15 Jan 2018 11:19:27 -0600
Ken Gaillot  wrote:

> On Mon, 2018-01-15 at 18:08 +0100, Klaus Wenninger wrote:
> > On 01/15/2018 05:51 PM, Ken Gaillot wrote:  
> > > Currently, Pacemaker will use the same detail log as corosync if
> > > one is
> > > specified (as "logfile:" in the "logging {...}" section of
> > > corosync.conf).
> > > 
> > > The corosync developers think that is a bad idea, and would like
> > > pacemaker 2.0 to always use its own log.
> > > 
> > > Corosync and pacemaker both use libqb to write to the logfile.
> > > libqb
> > > doesn't have any locking mechanism, so there could theoretically be
> > > some conflicting writes, though we don't see any in practice.
> > > 
> > > Does anyone have a strong opinion on this one way or the other? Do
> > > you
> > > like having pacemaker and corosync detail messages in one logfile,
> > > or
> > > would you prefer separate logfiles?  
> > 
> > I'm aware that a log-entry from one source (like corosync) appearing
> > before an entry from another source (like pacemaker) doesn't
> > necessarily
> > mean that this correctly reflects their sequence in time but usually
> > it is working fairly well.
> > With timestamps of 1 second granularity in 2 files we would be
> > definitely
> > off worse.
> > Please correct me if timestamping is configurable already but if not
> > I would say we should either have at least the possibility to log
> > into
> > a single file or we should have timestamping with a granularity at
> > least 3 magnitudes finer. (configurable timestamps as in pacemaker-
> > alerts
> > might be a solution)
> > 
> > Regards,
> > Klaus  
> 
> Configurable timestamps (or even just switching to high-precision
> timestamps permanently) sounds great. However that would require
> changes in libqb.
> 
> You can already get configurable timestamps in the syslog, via the
> native syslog functionality. That is more reliable than relying on the
> corosync vs pacemaker ordering in the detail log.
> 
> Better support in libqb for writing to the same logfile might be
> interesting, but it would require both high-precision timestamps and
> locking, which could impact performance. I'd prefer high-precision
> timestamps in separate files.

Log files are quite difficult to understand for novices, especially
understanding what piece of the stack is talking about compare to other ones
around.

Moreover, it's not natural to explain logs from Pacemaker are written in
corosync.log file on some distro.

Splitting Corosync and Pacemaker log make sense to me.

Having better precision in timestamp as well.

Handling multiple logs is easy from the system point of view anyway. And I agree
most of this job can be forwarded to syslog or journald.


___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Opinions wanted: another logfile question for Pacemaker 2.0

[Ken Gaillot]

On Mon, 2018-01-15 at 18:08 +0100, Klaus Wenninger wrote:
> On 01/15/2018 05:51 PM, Ken Gaillot wrote:
> > Currently, Pacemaker will use the same detail log as corosync if
> > one is
> > specified (as "logfile:" in the "logging {...}" section of
> > corosync.conf).
> > 
> > The corosync developers think that is a bad idea, and would like
> > pacemaker 2.0 to always use its own log.
> > 
> > Corosync and pacemaker both use libqb to write to the logfile.
> > libqb
> > doesn't have any locking mechanism, so there could theoretically be
> > some conflicting writes, though we don't see any in practice.
> > 
> > Does anyone have a strong opinion on this one way or the other? Do
> > you
> > like having pacemaker and corosync detail messages in one logfile,
> > or
> > would you prefer separate logfiles?
> 
> I'm aware that a log-entry from one source (like corosync) appearing
> before an entry from another source (like pacemaker) doesn't
> necessarily
> mean that this correctly reflects their sequence in time but usually
> it is working fairly well.
> With timestamps of 1 second granularity in 2 files we would be
> definitely
> off worse.
> Please correct me if timestamping is configurable already but if not
> I would say we should either have at least the possibility to log
> into
> a single file or we should have timestamping with a granularity at
> least 3 magnitudes finer. (configurable timestamps as in pacemaker-
> alerts
> might be a solution)
> 
> Regards,
> Klaus

Configurable timestamps (or even just switching to high-precision
timestamps permanently) sounds great. However that would require
changes in libqb.

You can already get configurable timestamps in the syslog, via the
native syslog functionality. That is more reliable than relying on the
corosync vs pacemaker ordering in the detail log.

Better support in libqb for writing to the same logfile might be
interesting, but it would require both high-precision timestamps and
locking, which could impact performance. I'd prefer high-precision
timestamps in separate files.
-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Opinions wanted: another logfile question for Pacemaker 2.0

[Klaus Wenninger]

On 01/15/2018 06:08 PM, Klaus Wenninger wrote:
> On 01/15/2018 05:51 PM, Ken Gaillot wrote:
>> Currently, Pacemaker will use the same detail log as corosync if one is
>> specified (as "logfile:" in the "logging {...}" section of
>> corosync.conf).
>>
>> The corosync developers think that is a bad idea, and would like
>> pacemaker 2.0 to always use its own log.
>>
>> Corosync and pacemaker both use libqb to write to the logfile. libqb
>> doesn't have any locking mechanism, so there could theoretically be
>> some conflicting writes, though we don't see any in practice.
>>
>> Does anyone have a strong opinion on this one way or the other? Do you
>> like having pacemaker and corosync detail messages in one logfile, or
>> would you prefer separate logfiles?
> I'm aware that a log-entry from one source (like corosync) appearing
> before an entry from another source (like pacemaker) doesn't necessarily
> mean that this correctly reflects their sequence in time but usually
> it is working fairly well.
> With timestamps of 1 second granularity in 2 files we would be definitely
> off worse.
> Please correct me if timestamping is configurable already but if not
> I would say we should either have at least the possibility to log into
> a single file or we should have timestamping with a granularity at
> least 3 magnitudes finer. (configurable timestamps as in pacemaker-alerts
> might be a solution)

Moving the time-handling-code from pacemaker to libqb anyway might not
be a bad idea.

Sorry for answering my own posts ;-)
Klaus

>
> Regards,
> Klaus
>
>> Note that this question only applies to the detail log; the syslog
>> would still get messages from everything (when configured).
>
> ___
> Users mailing list: Users@clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org



___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Opinions wanted: another logfile question for Pacemaker 2.0

[Klaus Wenninger]

On 01/15/2018 05:51 PM, Ken Gaillot wrote:
> Currently, Pacemaker will use the same detail log as corosync if one is
> specified (as "logfile:" in the "logging {...}" section of
> corosync.conf).
>
> The corosync developers think that is a bad idea, and would like
> pacemaker 2.0 to always use its own log.
>
> Corosync and pacemaker both use libqb to write to the logfile. libqb
> doesn't have any locking mechanism, so there could theoretically be
> some conflicting writes, though we don't see any in practice.
>
> Does anyone have a strong opinion on this one way or the other? Do you
> like having pacemaker and corosync detail messages in one logfile, or
> would you prefer separate logfiles?

I'm aware that a log-entry from one source (like corosync) appearing
before an entry from another source (like pacemaker) doesn't necessarily
mean that this correctly reflects their sequence in time but usually
it is working fairly well.
With timestamps of 1 second granularity in 2 files we would be definitely
off worse.
Please correct me if timestamping is configurable already but if not
I would say we should either have at least the possibility to log into
a single file or we should have timestamping with a granularity at
least 3 magnitudes finer. (configurable timestamps as in pacemaker-alerts
might be a solution)

Regards,
Klaus

>
> Note that this question only applies to the detail log; the syslog
> would still get messages from everything (when configured).


___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org