RE: slapd logging changes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:22 PM 10/2/00 -0400, Gary Williams wrote:
>> One tricky part of all this is that the
>> logging needs to be integrated with -lldap/-llber in a
>> way that does interfere with use in other applications.
>> In particular, an LDAP application must not be required
>> to link in -llutil.  However, OpenLDAP applications could
>> use an -llutil routine which plugged in the right stuff into
>> -lldap and -llber to get subsystem logging... [which is
>> quite appropriate if logging supports syslog].
>
>The only way I know to do this is to try to get fancy with
>macros.  I'll see what I can work out.

You likely would need to have per library macros which
used per library hooks to do logging.  If not overwritten,
then simple logging is done to stderr by the default handler
as control by some per library flag.   However, if lutil_log_init()
is called by the application (which could also be used to register
additional subsystems), the hooks would get replaced with a
fancier, shared logging routines.

>> Levels should be something similar to what syslog offers,
>> as these are well understood (and allows for OpenLDAP
>> logging to use syslog directly).
>
>I'm not sure I agree with this since the syslog levels are
>mostly designed around reporting information that a system
>administrator wants to see when things go wrong. 

syslog is designed to handle multiple levels, including
levels to provide great amount of detail needed for debugging
purposes.

>Debug
>information is more about what level of detail do you want
>to see about what's going on in a certain part of the code.

This is why we want per subsystems levels.


>> 
>> I believe that statistics should be either handled as
>> a separate subsystem and not as a level... or, alternative,
>> separate from the subsystem:level mechanism.
>
>Errors should, too.  Error logging and statistics should be
>independent of debug logging.  The production builds should
>still be able to output errors and stats.

I would argue that there is little difference between error
logging and debugging information.  One could argue same for
stats.

In a past life I designed and built a data distribution system.
What I did for logging here was to have separate macros for
each level:
        LogNotice( SUBSYSTEM, "format", ...)
        LogInfo( SUBSYSTEM, "format", ...)
        LogDebug( SUBSYSTEM, "format", ...)
        LogDevel( SUBSYSTEM, "format", ...)
        LogNoise( SUBSYSTEM, "format", ...)

When the system was build for production use, LogDevel and
LogNoise were not included in the resultant executable.
LogDebug was included to allow debugging of production code.


>> Decided what subsystems are needed is the easy part...
>> I'm happy with one subsytem for the main application,
>> one per library, one per backend, and one per other
>> (application defined?) major subsystem
>
>The only gotcha I see with this is, for instance, I want to
>see all the information on filters.  The front end pulls them
>out (of the request), the back end validates against them, and
>I may not want to see everything the front end or back end has
>to say about other things.  If we use the strings mechanism,
>we could specify multiple subsystems in the logging call:
>ldap_log( "BACK_LDBM | FILTERS", 2, "some filter logging" );

I don't believe it wise to allow such.  The developer needs
to pick the most appropriate subsystem.

Kurt