Re: logging

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Saturday 08 December 2007 01:42:02 Craig wrote:
> Hi, I was recently looking at our logs and trying to figure out what an
> appropriate logging level is for a stable, production system.
>
> What I would really like is a log (or logs) that contain:
> 	- the request made
> 	- the client (IP) that made the request

loglevel stats

> 	- how much time it took to answer the request

IMHO you should avoid using a logging system as a performance monitoring 
system.

> 	- any errors, with LDAP error codes

stats does this

> 		including errors with configs

If there are critical errors in the config, slapd won't start. If there are 
other errors, you should consider rather ensuring that the config is tested 
at an appropriate level before starting/restarting. slaptest -d config

(I note that if slapd fails to parse something ... the only way you will 
notice is if you look at the output of slaptest -d config)

> 	- syncrepl info, eg:
> 		"sync completed added 2 entries, changed 4"

If you want lots of verbosity including the previous logging:

loglevel stats sync

Is this *really* something you want to look at, or do you rather want to 
monitor whether the slave is in sync. I really prefer the latter, and that 
can be done with a monitoring tool that monitors the contextCSNs. I have a 
script that does that for use with hobbit:

http://staff.telkomsa.net/~bgmilne/hobbit/

You can see what the output normally looks like here:
http://staff.telkomsa.net/~bgmilne/hobbit/ol.html

> The current log level scheme doesn't seem to support that.

loglevel stats sync

seems to. Of course, whether this is the most sensible way to achieve what you 
want, we can't know, as you only told us how you want to do it (parse logs), 
not what you are trying to achieve (understand performance, ensure 
replication is occurring and that slaves are in sync?).

I feel the rest of your comments on logging are irrelevant until you tell us 
what you are trying to achieve (as logging might not be the best method).

Regards,
Buchan