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