On Fri, Mar 30, 2018 at 8:36 PM, Jehan-Guillaume de Rorthais < j...@dalibo.com> wrote:
> On Thu, 29 Mar 2018 09:32:41 +1100 > Andrew Beekhof <abeek...@redhat.com> wrote: > > > On Thu, Mar 29, 2018 at 8:07 AM, Jehan-Guillaume de Rorthais < > > j...@dalibo.com> wrote: > > > > > On Wed, 28 Mar 2018 15:50:26 -0500 > > > Ken Gaillot <kgail...@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 > > > pcmk-master > > > 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 > > > SP1 > > > 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. > > Yes. But sometime, messages are not so well mixed, with causes showing up > after > effects in logs... > > > 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... > > In my opinion, this is neither the role of libqb libqb has the logging library that pacemaker and corosync use. it is absolutely where this change should happen > or corosync...Or you would > have to include some more configuration params to be able to set the log > directory, file, format, rotation, etc. > > Maybe the easiest path is to rely on syslog/journald. They are both able > to log > with sub-second timestamps (at least journald do) and provide the > administrator > everything they need to deal with the logs. > > > 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 > > I think the best would be to have one log for Corosync, one log for > Pacemaker > (and all its sub-process/childs). > > Another good path toward understandable log file would be to hide what > process > is speaking. Experienced user will still know that "LOG: setting failcount > to 3" comes from CRMd and "DEBUG1: failcount setted to 3" comes from attrd. > > However, this would probably be a mess...because again, the cause might be > logged AFTER the effects/reaction :/ > why? i've never seen that be the case > > Maybe the solution is to log only messages from CRMD, where all the > orchestration comes from. Everything else might go to some debug level if > needed. > sorry, that is a terrible idea > > > > > 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 > > > by > > > 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 > > I'm doing some support as well, infrequently. I suppose crm_report is > probably > enough to gather previous CIB and compare them. > >
_______________________________________________ Users mailing list: Users@clusterlabs.org https://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