[Cluster-devel] logging: final call on configuration, output and implementation

[Steven Dake <sdake@redhat.com>]

On Tue, 2008-11-11 at 05:55 +0100, Fabio M. Di Nitto wrote:
> On Mon, 2008-11-10 at 17:46 -0700, Steven Dake wrote:
> > I disagree with a global debug keyword. 
> >  At one time I thought it was a
> > good idea but that time has long since passed.  The idea of turning
> > debug to on and then having all debug output go to syslog is frightening
> > and will result in lost messages.  While it appears this proposal
> > includes the selectable log output filtering per output medium as was
> > discussed already, it is unclear how the debug keyword affects this.  It
> > would simply make sense to change the file's log priority or the
> > syslog's log priority if that is the behavior desired and then no need
> > for any extra keyword.
> 
> You have these two situations:
> 
> print_log(LOG_DEBUG, "doing this and that....\n");
> 
> if (debug) { /*
>  gather_some_data_that_is_very_expensive_operation_to_do_all_the_time();
>  print_log(LOG_DEBUG, "print those extra data\n");
> }
> 
> as it is now, it would basically be an alias to set logpriority to DEBUG
> but enables people to execute debugging code conditionally and as I
> wrote it is an easy keyword to remember compared to
> syslog_priority/logpriority.
> 
> Fabio
> 

The second situation doesn't exist in any code I have written and never
would.  Having any conditional debug output is asking for trouble.  Been
down that road, done that, and discarded that idea...  The "debughi" or
high volume debug messages do not go through log_printf nor would they
be committed to any persistent log (only memory).  The output of the
logging message is significantly more expensive then that of gathering
logging data.

Turning debug on for all of the entire stack to be output to syslog is
not satisfactory because messages would be lost in overload conditions.
Logging to file is only a slight bit better solution but if you really
must have debug output in a persistent store that doesn't occur as a
result of a failure, logging to file is the only suitable answer.

A global debug option without selecting log output is not a workable
solution because of overload of syslog, even overload of the filesystem,
or other issues.

What makes sense is to have a mechanism to set the priority for each
specific log output mechanism and forget about any global debug option
nonsense.

Regards
-steve