Logging in Python
Logging is a handy tool in a programmer’s toolbox. It can help you develop a better understanding of the flow of a program and discover scenarios that you might not even have thought of while developing.
Logs provide developers with an extra set of eyes that are constantly looking at the flow that an application is going through. They can store information, like which user or IP accessed the application.
If an error occurs, then they can provide more insights than a stack trace by telling you what the state of the program was before it arrived at the line of code where the error occurred.
By logging useful data from the right places, you can not only debug errors easily but also use the data to analyze the performance of the application to plan for scaling or look at usage patterns to plan for marketing.
Logging in Python
Python provides a built-in library called logging to make it easy to add logging to any module or application in a unified way.
The logging module is part of the standard Python library and provides tracking for events that occur while the software runs. You can add logging calls to your code to indicate what events have happened.
The logging module allows for both diagnostic logging that records events related to an application’s operation, as well as audit logging which records the events of a user’s transactions for analysis. It is primarily used to record events to a file.
Python Logging Levels: The log level corresponds to the «importance» a log is given : an «error» log should be more urgent than the «warn» log, whereas a «debug» log should be useful only when debugging the application.
There are six log levels in Python; each level is associated with an integer that indicates the log severity:
- NOTSET=0 : Nothing is logged
- DEBUG=10 : These are used to give Detailed information, typically of interest only when diagnosing problems.
- INFO=20 : These are used to confirm that things are working as expected
- WARN=30 : These are used as an indication that something unexpected happened, or indicative of some problem in the near future
- ERROR=40 : This tells that due to a more severe problem, the software has not been able to perform some function
- CRITICAL=50 : This shows a severe error, indicating that the program itself may be unable to continue running
import logging logging.debug('This is a debug message') logging.info('This is an info message') logging.warning('This is a warning message') logging.error('This is an error message') logging.critical('This is a critical message')Configuring Logging
The main application should configure the logging subsystem so log messages go where they should. The Python logging module provides a large number of ways to fine-tune this, but for almost all applications, the configuration can be straightforward.
In general, a configuration consists of adding a Formatter and a Handler to the root logger. Because this is so common, the logging module provides a utility function called basicConfig that handles a majority of use cases.
Applications should configure logging as early as possible, preferably as the first thing in the application, so that log messages do not get lost during startup.
Finally, applications should wrap a try/except block around the main application code to send any exceptions through the logging interface instead of just to stderr.
Some of the commonly used parameters for basicConfig() are the following:
- level: The root logger will be set to the specified severity level.
- filename: This specifies the file.
- filemode: If filename is given, the file is opened in this mode. The default is a, which means append.
- format: This is the format of the log message.
Let’s see an example program.
import unittest import logging class Test(unittest.TestCase): #Create and configure logger logging.basicConfig(filename="newfile.log", format='%(asctime)s %(message)s', filemode='w') #Creating an object logger=logging.getLogger() #Setting the threshold of logger to DEBUG logger.setLevel(logging.DEBUG) def test_read_excel_column_file(self): logging.debug('This is a debug message') logging.info('This is an info message') logging.warning('This is a warning message') logging.error('This is an error message') logging.critical('This is a critical message') if __name__ == "__main__": unittest.main() 
Logging with selenium python
In similar ways, we can use the logger along with selenium python.
import unittest import logging class Test(unittest.TestCase): #Create and configure logger logging.basicConfig(filename="newfile.log", format='%(asctime)s %(message)s', filemode='w') #Creating an object logger=logging.getLogger() #Setting the threshold of logger to DEBUG logger.setLevel(logging.DEBUG) def test_read_excel_column_file(self): logging.debug('This is a debug message') logging.info('This is an info message') logging.warning('This is a warning message') logging.error('This is an error message') logging.critical('This is a critical message') if __name__ == "__main__": unittest.main()Logging to console with python
To log the statement to the console, you just need to remove the fileName option in the basicConfig.
import unittest import logging class Test(unittest.TestCase): #Create and configure logger logging.basicConfig(filename="newfile.log", format='%(asctime)s %(message)s', filemode='w') #Creating an object logger=logging.getLogger() #Setting the threshold of logger to DEBUG logger.setLevel(logging.DEBUG)Print vs. Logging
The logging package has a lot of useful features which are missing in print statements:
- Easy to see where and when (even what line no.) a logging call is being made from.
- You can log to files, sockets, pretty much anything, all at the same time.
- You can differentiate your logging based on the severity
Recommended Readings
I am Pavankumar, Having 8.5 years of experience currently working in Video/Live Analytics project.
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Logging
This wiki is not where you want to be! Visit the Wiki Home for more useful links
For Developers and Contributors
Binding Specific Information
This content is being evaluated for where it belongs
Clone this wiki locally
Logging is important both for developers and users of WebDriver. Users might need to be able to find details about why a test failed, while developers might need to be able to find details of why WebDriver in itself failed. Good logging support can make these debugging tasks much easier.
WebDriver may be used in different kinds of configurations. For instance, a client running a test may be connected directly to a a driver controlling a browser, or a client may be connected indirectly to a driver via a server. Depending on the configuration different kinds of logs may be available. With this in mind, the system should provide means to query for available log types.
In general, to debug a certain configuration it is useful to have access to logs from each of the nodes in the configuration. That is, from the client, server, driver, and the browser. Still, logs for all these nodes may not be available in all configurations. The server log being the simple example, but logs may also not be supported, or possible to retrieve due to the browser. In addition, there may be more logs available than the mentioned baseline. For instance, there may be support for logs specifically collecting performance data.
| Log type | Meaning |
|---|---|
| browser | Javascript console logs from the browser |
| client | Logs from the client side implementation of the WebDriver protocol (e.g. the Java bindings) |
| driver | Logs from the internals of the driver (e.g. FirefoxDriver internals) |
| performance | Logs relating to the performance characteristics of the page under test (e.g. resource load timings) |
| server | Logs from within the selenium server. |
For more information on which command to use to retrieve available log types, and a baseline of general log types, please view the wire protocol.
A log corresponds to a list of log entries, where each log entry is a tuple containing a timestamp, a log level, and a message.
The purpose of log levels is to provide a means to filter the messages in the log based on level of interest. For instance, if the purpose is debugging then more or less all messages may be of interest, while if the purpose is general monitoring then less information may be needed.
For WebDriver the following log levels have been selected (ordered from highest to lowest):
- OFF: Turns off logging
- SEVERE: Messages about things that went wrong. For instance, an unknown command.
- WARNING: Messages about things that may be wrong but was handled. For instance, a handled exception.
- INFO: Messages of an informative nature. For instance, information about received commands.
- DEBUG: Messages for debugging. For instance, information about the state of the driver.
- ALL: All log messages. A way to collect all information regardless of which log levels that are supported.
Languages like Java and Python typically provide a logging API with its own log levels, each with a name and a number, while the WebDriver log levels described above are described with names in a certain order (and no numbers). Driver implementors may use the log levels of their host language, but should translate the log levels of the host language to WebDriver log levels before sending logs over the wire.
Please see the wire protocol for more details.
In general, a log message is just a string. Still, some log types may have a need for more structured information, for instance, to separate between different kinds of log messages. For such log types, the message part of a log entry may be structured as a JSON object. For cases where this is the practice it should be clear from the documentation.
Provided that a log type is supported, it should be possible to retrieve the corresponding log. For remote logs on a different node, retrieval involves the use of the wire protocol. In the scenario where a log is retrieved several times the same log entries should not be retrieved more than once. For this reason, and to same memory, after each retrieval of a log the log buffer of that log is reset.
Please see the wire protocol for more details.
Configuration of Logging Behavior
There may be cases where logging should be turned off entirely, or the number of logged messages should be fewer. For instance, a driver may be running on a device with limited resources. To support such cases it should be possible to configure logging behavior as a capability. A logging configuration of this kind corresponds to a list of pairs where log types are mapped to log levels. Since OFF is included as a log level a means for turning off logging is provided.
The default behavior should be to collect all log messages and let the client do filtering as needed. For cases where a different log level has been configured for a log type, messages under that log level should not be collected.
Please see the capabilities page for more information about logging configuration.
Browser Specific Behavior
Merging of the Browser and Driver Logs
The Firefox driver provides an additional capability to configure whether the browser and driver log should be merged. In practice, this means that the driver log entries are printed to the error console of the browser, in addition to being collected elsewhere.
The default behavior is to merge the logs, the reason being that the error console of the browser provides a simple way to get a merged graphical view of the joined logs.
Please see the capabilities page for more information about Firefox specific capabilities.