RE: slapd logging changes

[Gary Williams <Gary.Williams@sas.com>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Friday, September 29, 2000 3:54 PM
> To: Gary Williams
> Cc: 'openldap-devel@openldap.org'
> Subject: Re: slapd logging changes
> 
> 
> I'd like to see this generalized a bit to support other
> OpenLDAP applications.  That is, the logging system should
> support not only slapd, but slurpd and even the client tools.
> It's just that the some applications have less subsystems
> than others.  

The most general scheme is to use character strings for
all logging calls.  The routine to set levels would look
for the string in an array and add it or update it.  The
logging routines would also use strings for logging.  This
means that the logging subsystems would be completely
arbitrary.  A client could use the routines to add their
own subsystems, and use them for logging.  A set of
known subsystems could have their strings defined in
ldap_log.h.  This would ease the problem of strings not
matching in the set level call and the logging call (
but not eliminate it).

> 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.

> 
> Also, I think "application" (or "main") should be added as a
> subsystem to provide control over logging within the main
> body of the application.  Also, logging should be configured
> via command line directives as one often needs logging before
> any configuration file can be read.  This is especially
> true for slapd.

This is easy either way.

> 
> I also would like to see mnemonics introduced for levels.
> Mnemonics will promote more consistent usage.

This is easy, too.

> 
> 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.  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.

> 
> 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.

> 
> At 02:17 PM 9/29/00 -0400, Gary Williams wrote:
> >How the subsystems are broken up warrants further discussion,
> 
> 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" );

Then if logging for either the "BACK_LDBM" or "FILTERS"
subsystems are set at 2 or more, the string would be output.

> 
> >but this is the basic mechanism.
> 
>  From the various posts I've seen on this subject, folks
> seem to agree that subsystem:level mechanism is fine.
> 
> Are there other design considerations which need to be
> taken into account?
> 
> 
> 
> 
>