Log hygiene

Some general recommendations regarding logging to futuretense.txt

• If the log is filling up with noise, resist the urge to suppress loggers to ERROR, WARN or FATAL without knowing what they are telling you. If something is frequently seen in the log then you should try to understand what it means, to know if action is needed. Only suppress loggers when you know the messages are harmless. At INFO level, CS is typically not very noisy.
  
  
• If you don't know what an error message is telling you, try to find out by checking the documented errorcodes or examining the stack trace. If you can't find out what a message means, ask Support.

• As of CS7.6, log4j is an option during installation, and is in most cases preferable over commons-logging. Log4j is more configurable, and you can change log levels on the fly without requiring a restart. One downside to log4j is that there is no out-of-the-box way to have per-ip logfiles, it requires some extra work.

• Log4j lets you define the format of log messages, such as:
  
  log4j.appender.FWDefaultAppender.layout.ConversionPattern=[%d][%t][%c][%p] %m%n
  
  This example format includes the most useful information, in particular the full name of the logger, and the thread ID that originated the message. When many thread are writing to the same log, you can separate out message using the thread ID.
  

• Consider using a new logger for any customization rather than relying on the default logger which is "com.fatwire.logging.cs". The ics:logmsg tag can let you specify the name of a logger, which you can define in log4j.properties or commons-logging.properties and so doing isolate your customization's logging from anything CS writes.
  
  
• Set the log rolling to something reasonable, e.g. sufficient to capture the whole day's activity and archive it. You may want to refer back to it for troubleshooting. You can configure the log to roll on a particular size threshold, and how many copies to keep.