Here are some guidelines I tried to implement in my own OpenSource logging unit, but it's fairly generic, and as you state, it should be suitable for any logging package:
- Make several levels (we use sets) of logging, to tune the logging information needed;
- Log all exceptions, even the handled one with a
try...except block - and add an exception classes list not worth logging (e.g. EConvertError) - e.g. our unit is able to log all exceptions via a global exception "hook" (no try..except to add in your code), and handle a list of exception classes to be ignored;
- Log all "fatal" errors, like database connection issues, or wrong SQL syntax - should be done though "log all exceptions" previous item;
- For such exceptions, log the stack trace to know about the calling context;
- Be able to log all SQL statements, or database access;
- Add a generic User Interface logging, to know which main functions of the software the User did trigger (e.g. for every toolbar button or menu items): it's very common that the user said 'I have this on my screen/report, but I didn't do anything'... and when you see the log, you will discover that the "anything" was done. ;)
- Monitor the main methods of your application, and associated parameters;
- Logging is an evolving feature: use those general rules above, then tune your logging from experiment, according to your debugging needs.