Python Loguru logging solution

introduce

For the logging module, even for simple use, you need to define the format yourself. Here is a more elegant, efficient, and concise third-party module: loguru. The official introduction is: Loguru is a library which aims to bring enjoyable logging in Python. Loguru aims to bring pleasant logging to Python. Here is an official GIF to quickly demonstrate its functionality:

1. Installation

Loguru only supports Python 3.5 and above, just use pip to install:

pip install loguru

2. Out of the box

The main concept of Loguru is that there is only one: logger

from loguru import logger

logger.info("This is log info!")
logger. warning("This is log warn!")
logger. error("This is log error!")
logger. debug("This is log debug!")

It can be seen that there is no need for manual settings, Loguru will configure some basic information in advance, automatically output time, log level, module name, line number and other information, and according to different levels, it also automatically sets different colors for easy observation and real Arrived out of the box!

3. Customization

add() / remove()

What if you want to customize the log level, customize the log format, and save the log to a file? Unlike the logging module, there is no need for a Handler or a Formatter, and only one add() function is needed. For example, if we want to store the log in a file:

from loguru import logger

logger. add('test. log')
logger. debug('this is a debug')

We don't need to declare a FileHandler like the logging module, just one line of add() statement to get it done, and after running, we will find that the debug information just output from the console also appears in the test.log under the directory.

Contrary to the add() statement, the remove() statement can remove the configuration we added:

from loguru import logger

log_file = logger.add('test.log')
logger. debug('This is log debug!')
logger. remove(log_file)
logger.debug('This is another log debug!')

At this point, the console will output two debug messages:

2021-10-19 13:53:36.610 | DEBUG | __main__:<module>:86 - This is log debug!
2021-10-19 13:53:36.611 | DEBUG | __main__:<module>:88 - This is another log debug!

And there is only one debug message in the test.log log file, the reason is that we used the remove() statement before the second debug statement.

4. Complete parameters

Loguru has very powerful support for output to file configuration, such as supporting output to multiple files, output by level, creating a new file if it is too large, automatically deleting it if it is too long, and so on. Let's take a closer look at the detailed parameters of the add() statement:

Basic syntax:

add(sink, *, level='DEBUG', format='<green>{time:YYYY-MM-DD HH:mm:ss.SSS}</green> | <level>{level: <8}</ level> | <cyan>{name}</cyan>:<cyan>{function}</cyan>:<cyan>{line}</cyan> - <level>{message}</level>', filter= None, colorize=None, serialize=False, backtrace=True, diagnose=True, enqueue=False, catch=True, **kwargs)

• sink: It can be a file object, such as sys.stderr or open('file.log', 'w'), or it can be a str string or a pathlib.Path object, that is, a file path, or it can be a method. Define the output implementation by yourself, it can also be a Handler of the logging module, such as FileHandler, StreamHandler, etc., or it can be a coroutine function, that is, a function that returns a coroutine object, etc.
• level: log output and save level.
• format: log format template.
• filter: An optional directive that decides whether each logged message should be sent to the sink.
• colorize: Whether color markers included in formatted messages should be converted to ansi codes for terminal coloring, or otherwise stripped. If not, the choice is made automatically based on whether the sink is a tty (short for teletypewriter).
• serialize: Whether logged messages should first be converted to JSON strings before being sent to the sink.
• backtrace: Whether the formatted exception trace should expand upwards, beyond the catch point, to show the full stack trace of the generating error.
  -diagnose: Whether exception traces should display variable values to simplify debugging. It is recommended to set False in a production environment to avoid leaking sensitive data.
• enqueue: Whether messages to be logged should first go through a multi-process safe queue before reaching the sink, this is useful when logging to a file through multiple processes, this also has the benefit of making the logging call non-blocking.
• catch: Whether errors that occur when the sink processes log messages should be automatically caught, if True, the exception message will be displayed on sys.stderr, but the exception will not be propagated to the sink, preventing the application from crashing.
• **kwargs: additional arguments valid only for configuration coroutines or file sinks (see below).
  If and only if sink is a coroutine function, the following parameters apply:
• loop: The event loop in which asynchronous logging tasks will be scheduled and executed. If None, the loop returned by asyncio.get_event_loop() will be used.
  The following parameters apply if and only if sink is a file path:
• rotation: A condition indicating when the currently recorded file should be closed and a new one started.
• retention : A directive to filter out old files, which are deleted during the loop or at the end of the program.
• compression: The compression or archive format the log file should be converted to when it is closed.
• delay: Whether to create the file immediately after configuring the sink, or delay until the first logged message. Default is False.
• mode: The opening mode of the built-in open() function, the default is a (open the file in append mode).
• buffering: The buffering strategy of the built-in open() function, the default is 1 (line buffered files).
• encoding: The file encoding of the built-in open() function, if None, defaults to locale.getpreferredencoding().
• **kwargs: Additional arguments passed to the built-in open() function.

With so many parameters, we can see the power of the add() function. Only one function can realize many functions of the logging module. Next, we will introduce several commonly used methods.

rotation log file separator

The rotation parameter of the add() function can create a new log file at a fixed time

For example, set to create a new log file at 0:00 every day:

logger.add('runtime_{time}.log', rotation='00:00')

Create a new log file with settings larger than 500 MB:

logger.add('runtime_{time}.log', rotation="500 MB")

Set to create a new log file every other week:

logger.add('runtime_{time}.log', rotation='1 week')

retention log retention time

The retention parameter of the add() function can set the maximum retention time of the log

For example, set log files to be kept for up to 15 days:

logger.add('runtime_{time}.log', retention='15 days')

Set log files to keep at most 10:

logger.add('runtime_{time}.log', retention=10)

Can also be a datetime.timedelta object

For example, set log files to be kept for up to 5 hours:

import datetime
from loguru import logger

logger.add('runtime_{time}.log', retention=datetime.timedelta(hours=5))

compression log compression format

The compression parameter of the add() function can configure the compression format of the log file, which can save more storage space

For example, the settings are saved in zip file format:

logger.add('runtime_{time}.log', compression='zip')

Its formats support: gz, bz2, xz, lzma, tar, tar.gz, tar.bz2, tar.xz

String formatting

Loguru also provides a very friendly string formatting function when outputting the log, which is equivalent to str.format():

logger.info('If you are using Python {}, prefer {feature} of course!', 3.6, feature='f-strings')

output:

2021-10-19 14:59:06.412 | INFO | __main__:<module>:3 - If you are using Python 3.6, prefer f-strings of course!

Exception traceback

In Loguru, you can directly use the decorators it provides to capture exceptions directly, and the logs obtained are extremely detailed:

from loguru import logger


@logger.catch
def my_function(x, y, z):
     # An error? It's caught anyway!
     return 1 / (x + y + z)


my_function(0, 0, 0)

Log output:

2021-10-19 15:04:51.675 | ERROR | __main__:<module>:10 - An error has been caught in function '<module>', process 'MainProcess' (30456), thread 'MainThread' (26268):
Traceback (most recent call last):

> File "D:/python3Project\test.py", line 10, in <module>
     my_function(0, 0, 0)
     └ <function my_function at 0x014CDFA8>

   File "D:/python3Project\test.py", line 7, in my_function
     return 1 / (x + y + z)
                 │ │ └ 0
                 │ └ 0
                 └ 0

ZeroDivisionError: division by zero

The output in the console is this:

Compared with Logging, Loguru is far superior to Logging in terms of configuration, log output style, and exception tracking. Using Loguru can undoubtedly improve developer efficiency