Logging¶

Critical information about the execution of CAMS should be displayed to the user through the Graphical User Interface. Nevertheless, less important pieces of information that are only useful to developers to diagnose the system can be recorded in logs. Messages can be also displayed in the terminal window.

Note: print statements must not be used to issue messages about the state of CAMS. This is because 1) Standard text output cannot be traced back to the file and line of code where it has been created; 2) Messages can not be shown or hidden according to their severity 3) Messages cannot be easily recorded for further analysis.

CAMS logging configuration¶

Logging in CAMS uses python logging library

Python loggers are typically named after the module they are defined in (i.e.: nephelae.database.CloudData) From the advanced python logging tutorial

A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

This means that logger names track the package/module hierarchy, and it’s intuitively obvious where events are logged just from the logger name.

CAMS uses this scheme with loggers defined per module/file. Because the CAMS code base layout is one class = one module, the number of logger objects can be big. Check if this extensive logging approach has in impact in performance

The recommended logger initialization in CAMS is:

import logger
logger = logging.getLogger(__name__)

at the begging of every file that logs messages, located before any module imports .

The python logging guide recommends adding the empty handler be default to prevent "No handlers could be found for logger X.Y.Z" messages from appearing.

import logging
logging.getLogger(__name__).addHandler(logging.NullHandler())

Django configures handlers by default so there is no risk for CAMS unless libraries are used independently.

See also¶

Configuring Logging for a Library
Good logging practice in Python