Revision as of 16:44, 20 December 2010 (view source) Tgalvin (Talk | contribs) (→Main Log) ← Older edit		Revision as of 09:19, 29 December 2010 (view source) Tvainio (Talk | contribs) (→Logging) Newer edit →
Line 1:		Line 1:
	= Logging =		= Logging =
-	== Levels ==	+	== Log Levels ==
-	* ''info'', ''error'' and ''warning'' for end user messages	+	Different log levels are targeted for different user groups.
-	* ''debug'' for developers	+	=== For Basic Users ===
		+
		+	''These are available in the centralized 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.
	== Logs ==		== Logs ==

---

Revision as of 09:19, 29 December 2010

Contents 1 Logging 1.1 Log Levels 1.1.1 For Basic Users 1.1.2 For Advanced User / Worker Maintainer and Server Maintainer 1.2 Logs 1.2.1 Main Log 1.2.2 Server Log 1.2.3 Worker Log 1.2.4 Conductor Log 1.2.5 Apache Log 1.3 Http Logger

Logging

Log Levels

Different log levels are targeted for different user groups.

For Basic Users

These are available in the centralized 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.

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.