The default of loglevel 256 is really the best bet. There's a corollary to this when problems *do* arise, don't try to trace them using syslog. Use the debug flag instead, and capture slapd's stderr output. syslog is too slow for debug tracing, and it's inherently lossy - it will throw away messages when it can't keep up.
Contrary to popular belief, loglevel 0 is not ideal for production as you won't be able to track when problems first arise.
The most common message you'll see that you should pay attention to is:
"<= bdb_equality_candidates: (foo) index_param failed (18)"
That means that some application tried to use an equality filter (foo=<somevalue>) and attribute foo does not have an equality index. If you see a lot of these messages, you should add the index. If you see one every month or so, it may be acceptable to ignore it.
The default syslog level is 256 which logs the basic parameters of each request; it usually produces 1-3 lines of output. On Solaris and systems that only provide synchronous syslog, you may want to turn it off completely, but usually you want to leave it enabled so that you'll be able to see index messages whenever they arise. On Linux you can configure syslogd to run asynchronously, in which case the performance hit for moderate syslog traffic pretty much disappears.
You can improve logging performance on some systems by configuring syslog not to sync the file system with every write (man syslogd/syslog.conf). In Linux, you can prepend the log file name with a "-" in syslog.conf. For example, if you are using the default LOCAL4 logging you could try:
# LDAP logs
LOCAL4.* -/var/log/ldap
For syslog-ng, add or modify the following line in syslog-ng.conf:
options { sync(n); };
where n is the number of lines which will be buffered before a write.
