Logging Levels and Scope

The Python logging module provides five levels of detail. Table 2-3 provides details on when to use each level.

Table 2-3. Logging Levels and When You Should Use Each

Level

When to Use

DEBUG As the name suggests, this logging level is for debugging purpose. Use DEBUG to log as much information as possible; messages at this level should contain enough detail for you to identify possible problems with the code.

INFO This is a less detailed level, and it's usually used to log key events in the system's life cycle, such as contacting an external service or calling a rather complicated subsystem.

WARNING Report all unexpected events with this logging level. Everything that is not harmful but is out of the ordinary should be reported here. For example, if a configuration file is not found, but we have default settings, we should raise a warning.

ERROR Use this level to log any event that prevents us from completing a given task, but still allows us to proceed with the remaining tasks. For example, if we need to check the status of five virtual servers, but one of them cannot be found, report this as an error, and proceed with checking other servers.

CRITICAL If you cannot proceed any further, log the error with this logging level and exit. There is no need to provide detailed information at this point; when it comes to troubleshooting, you will switch to lower level, such as DEBUG.

It is very important to think about the scope and purpose of your logging. You must differentiate between regular output from the tool and logging. Regular output and reporting are the primary functions of the tool and thus must not mix with the logging message from the application. You might choose to use the logging module to write application output messages as well, but they need to go to a different stream. Application logging is purely for reporting the status of the application.

For example, if we are not able to connect to the load balancer, we must log that as a critical event and quit. In other words, something happened to our tool that prevented it from finishing its operation. However, if we get the temperature reading and decided that it is too far from normal, we must not log this as critical in our log stream, because high system temperature has nothing to do with our application. Regardless of the load balancer health, our tool behaves and functions correctly. Continuing with this example, we might decide either to simply print the warning message or to log it in some other stream, possibly called loadbalancers_health. log.

Was this article helpful?

0 0

Post a comment