<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais <span dir="ltr"><<a href="mailto:jgdr@dalibo.com" target="_blank">jgdr@dalibo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, 29 Mar 2018 09:32:41 +1100<br>
Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>> wrote:<br>
<br>
> On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais <<br>
> <a href="mailto:jgdr@dalibo.com">jgdr@dalibo.com</a>> wrote:<br>
><br>
> > On Wed, 28 Mar 2018 15:50:26 -0500<br>
> > Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br>
> > [...]<br>
> > > > >  pacemakerd: PREFIX-launchd, PREFIX-launcher<br>
> > > ><br>
> > > > pacemakerd, alone, sounds perfectly fine to me.<br>
> > ><br>
> > > Agreed -- but the argument against it is to allow something like "grep<br>
> > > pcmk /var/log/messages" to get everything.<br>
> ><br>
> > Then I would pick PREFIX-master... But then I would hate having a<br>
> > pcmk-master<br>
> > process :(<br>
> ><br>
> > Maybe all the logging information should be handled by one process so<br>
> > syslog/journald/stderr are happy?<br>
> ><br>
> > Despite it's multiprocess architecture, PostgreSQL either:<br>
> ><br>
> > * emit to syslog/journald using the same ident for all process<br>
> > * capture stderr of all process and redirect to one file.<br>
> ><br>
> > [...]<br>
> > > > >  cib: PREFIX-configd, PREFIX-state<br>
> > > ><br>
> > > > Tricky...It deals with both config and state...<br>
> > > ><br>
> > > > By the way, why in the first place the CIB messages must be in the<br>
> > > > log file?<br>
> > > > Filling logs with XML diffs resulting from other actions already<br>
> > > > logged earlier<br>
> > > > sounds like duplicated informations.<br>
> > ><br>
> > > They are kept out of the syslog, which is where most users are expected<br>
> > > to look. They are in the detail log, which is for more advanced<br>
> > > troubleshooting.<br>
> ><br>
> > oh ok, sorry.<br>
> ><br>
> > I just finished a day reading log file /var/log/pacemaker.log on a Suse 12<br>
> > SP1<br>
> > that was packed with XML diffs :/<br>
> ><br>
> > Maybe I should have checked /var/log/messages or the syslog setup...<br>
> ><br>
> > But honestly, I hate having mixed logs all packed in one same files<br>
> > like /var/log/messages :/<br>
> ><br>
><br>
> Theres a very good reason for it though - the relative timing of events is<br>
> the only way to establish cause and effect.<br>
<br>
</div></div>Yes. But sometime, messages are not so well mixed, with causes showing up after<br>
effects in logs...<br>
<span class=""><br>
> Though by now there is surely a decent library for logging to files with<br>
> sub-second timestamps - if we could incorporate that into libqb and have<br>
> corosync use it too...<br>
<br>
</span>In my opinion, this is neither the role of libqb</blockquote><div><br></div><div>libqb has the logging library that pacemaker and corosync use.</div><div>it is absolutely where this change should happen</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> or corosync...Or you would<br>
have to include some more configuration params to be able to set the log<br>
directory, file, format, rotation, etc.<br>
<br>
Maybe the easiest path is to rely on syslog/journald. They are both able to log<br>
with sub-second timestamps (at least journald do) and provide the administrator<br>
everything they need to deal with the logs.<br>
<span class=""><br>
> then we could consider 1 log per daemon.<br>
> In which case, the outcome of the PREFIX-SUFFIX discussion above could<br>
> instead be used for /var/log/pacemaker/SUFFIX<br>
<br>
</span>I think the best would be to have one log for Corosync, one log for Pacemaker<br>
(and all its sub-process/childs).<br>
<br>
Another good path toward understandable log file would be to hide what process<br>
is speaking. Experienced user will still know that "LOG: setting failcount<br>
to 3" comes from CRMd and "DEBUG1: failcount setted to 3" comes from attrd.<br>
<br>
However, this would probably be a mess...because again, the cause might be<br>
logged AFTER the effects/reaction :/<br></blockquote><div><br></div><div>why?  i've never seen that be the case</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe the solution is to log only messages from CRMD, where all the<br>
orchestration comes from. Everything else might go to some debug level if<br>
needed.<br></blockquote><div><br></div><div>sorry, that is a terrible idea</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > > The detail log messages are useful mainly because CIB changes can come<br>
> > > from external sources, not just cluster daemons,<br>
> ><br>
> > Sure, but a simple info messages explaining that «the CIB has been updated<br>
> > by<br>
> > tool "<tool_here>" » sound enough to me.<br>
> ><br>
><br>
> to you, because you know what you changed.<br>
> anyone else reading the logs (ie. people doing support) hasn't got a clue<br>
> and knowing who changed what is crucial to understanding what the cluster<br>
> did and why<br>
<br>
</span>I'm doing some support as well, infrequently. I suppose crm_report is probably<br>
enough to gather previous CIB and compare them.<br>
<br>
</blockquote></div><br></div></div>