Revision as of 10:28, 31 December 2010

Logging

Log Levels

Different log levels are targeted for different user groups. See Typical OTS users and usage scenarios for more information.

For Basic Users

These are available in the centralized testrun http log.

• INFO shows what's happening in high level
  • What parameters where used for the request
  • What's happening right know. (Downloading image x from http://..., Flashing, Executing package asdf-tests.)

• ERROR shows what went wrong.
  • It needs to be explained so that the basic user can understand it
  • Always think from the basic user point of view. What makes sense to you as a developer probably does not make sense for the user at all.
  • Don't say "_get_file("tests.xml") failed!", say "Testpackage asdf-tests is not in the image".
  • Tracebacks are always good if they provide additional information for debugging. Just make sure that the actual error message is still there. Most of the users don't know python and do not want to read tracebacks. Instead of "Error! Traceback follows:", say "Custom flasher was not able to flash the image:". Then the basic user gets a rough idea what's going on and system maintainer/ots developer can solve the issue by looking at the traceback.

• WARNING warns if something is wrong but it's not critical
  • For example user gives unknown input parameter. It might be a typo so the user should be warned.

For Advanced User / Worker Maintainer and Server Maintainer

These logs are available in log files. Currently server debug log for each testrun is in /var/log/ots/. Conductor logs to ~/conductor.log in the worker machine. OTS worker process logs to /var/log/ots.log.

• DEBUG on worker components
  • In most cases INFO and ERROR level messages should be enough but we expect worker maintainers to be able to follow also DEBUG level messages
  • DEBUG messages should give enough information to sort out problems in the worker setup.
  • Don't say "calling flasher...". Say "executing command '/usr/bin/flasher -f imagefile'"
  • Don't log too much. It makes reading the log difficult. Tracebacks should tell where we were when error happened.
  • Input parameters and sub commands (parameters, return values, stdout, stderr) are likely to be valuable information when debugging.

How to Log Exceptions

Logging record objects have exc_info field and that should be used. No need to format or include the exception in the actual log message. This way it's easy to format every exception properly in the logging handlers or views. Current http logger views use this.

• In exception handlers it's enough to do

log.exception("Catastrophic error")

or

log.debug("Catastrophic error", exc_info=True)

If exception is received as an object, it can be logged properly like this:

except Exception, err:
log.error("Catastrophic error", exc_info=err)

or if it's the common (Type, Value, Traceback) tuple:

def __exit__(self, exception_type, value, tb):
    LOG.warning("Error in plugin", exc_info=(exception_type, value, tb))

Logs

There are a number of ways to view the OTS testrun:

Main Log

The Main OTS log is written to

/var/log/ots

Server Log

This is configurable by the 'logging.conf' file in the root directory

Worker Log

The Worker can be configured to log to a file specified by the "log_file" parameter in the Worker config file.

Conductor Log

Writes to the <ahem> home directory

/path/to/home/conductor.log

Apache Log

If you are running OTS with Apache:

/var/log/apache2/error.log

Http Logger

In addition there is an http_logger.