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.
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 to run the following code before any module imports:
_logger = logging.getLogger(__name__)
Single leading underscore indicates that the object is not part of the public API.
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.
Django configures handlers by default so there is no risk for CAMS unless libraries are used independently.
Setup the log level¶
Environment variables control the log level by setting them to one of
DJANGO_LOG_LEVELdjango related loggers
CAMS_LOG_LEVELgeneral log level (cams libraries and external)
Detailed configuration options are found in the django settings for the gui project (