Содержание страницы
Сборник рецептов по логированию¶Logging Cookbook
- Автор
Vinay Sajip <vinay_sajip at red-dove dot com>
На этой странице представлен ряд рецептов, связанных с логированием, которые оказались полезными на практике.
Использование логирования в нескольких модулях¶Using logging in multiple modules
Многократные вызовы logging.getLogger('someLogger') возвращают ссылку на один и тот же объект логгера. Это верно не только в пределах одного модуля, но и для разных модулей, если они выполняются в одном процессе интерпретатора Python. Кроме того, код приложения может определить и настроить родительский логгер в одном модуле, а затем создать (но не настраивать) дочерний логгер в другом модуле – все вызовы логгера у дочернего будут передаваться родительскому. Вот главный модуль:
import logging
import auxiliary_module
# создать логгер с именем 'spam_application'
logger = logging.getLogger('spam_application')
logger.setLevel(logging.DEBUG)
# создать файловый обработчик, записывающий даже отладочные сообщения
fh = logging.FileHandler('spam.log')
fh.setLevel(logging.DEBUG)
# создать консольный обработчик с более высоким уровнем логирования
ch = logging.StreamHandler()
ch.setLevel(logging.ERROR)
# создать форматтер и добавить его к обработчикам
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
fh.setFormatter(formatter)
ch.setFormatter(formatter)
# добавить обработчики к логгеру
logger.addHandler(fh)
logger.addHandler(ch)
logger.info('creating an instance of auxiliary_module.Auxiliary')
a = auxiliary_module.Auxiliary()
logger.info('created an instance of auxiliary_module.Auxiliary')
logger.info('calling auxiliary_module.Auxiliary.do_something')
a.do_something()
logger.info('finished auxiliary_module.Auxiliary.do_something')
logger.info('calling auxiliary_module.some_function()')
auxiliary_module.some_function()
logger.info('done with auxiliary_module.some_function()')
А вот вспомогательный модуль:
import logging
# создать логгер
module_logger = logging.getLogger('spam_application.auxiliary')
class Auxiliary:
def __init__(self):
self.logger = logging.getLogger('spam_application.auxiliary.Auxiliary')
self.logger.info('creating an instance of Auxiliary')
def do_something(self):
self.logger.info('doing something')
a = 1 + 1
self.logger.info('done doing something')
def some_function():
module_logger.info('received a call to "some_function"')
Вывод выглядит так:
2005-03-23 23:47:11,663 - spam_application - INFO -
creating an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,665 - spam_application.auxiliary.Auxiliary - INFO -
creating an instance of Auxiliary
2005-03-23 23:47:11,665 - spam_application - INFO -
created an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,668 - spam_application - INFO -
calling auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,668 - spam_application.auxiliary.Auxiliary - INFO -
doing something
2005-03-23 23:47:11,669 - spam_application.auxiliary.Auxiliary - INFO -
done doing something
2005-03-23 23:47:11,670 - spam_application - INFO -
finished auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,671 - spam_application - INFO -
calling auxiliary_module.some_function()
2005-03-23 23:47:11,672 - spam_application.auxiliary - INFO -
received a call to 'some_function'
2005-03-23 23:47:11,673 - spam_application - INFO -
done with auxiliary_module.some_function()
Журналирование из нескольких потоков¶Logging from multiple threads
Журналирование из нескольких потоков не требует особых усилий. В следующем примере показано журналирование из главного (начального) потока и ещё одного потока:
import logging
import threading
import time
def worker(arg):
while not arg['stop']:
logging.debug('Hi from myfunc')
time.sleep(0.5)
def main():
logging.basicConfig(level=logging.DEBUG, format='%(relativeCreated)6d %(threadName)s %(message)s')
info = {'stop': False}
thread = threading.Thread(target=worker, args=(info,))
thread.start()
while True:
try:
logging.debug('Hello from main')
time.sleep(0.75)
except KeyboardInterrupt:
info['stop'] = True
break
thread.join()
if __name__ == '__main__':
main()
При запуске скрипт должен вывести что-то вроде следующего:
0 Thread-1 Hi from myfunc
3 MainThread Hello from main
505 Thread-1 Hi from myfunc
755 MainThread Hello from main
1007 Thread-1 Hi from myfunc
1507 MainThread Hello from main
1508 Thread-1 Hi from myfunc
2010 Thread-1 Hi from myfunc
2258 MainThread Hello from main
2512 Thread-1 Hi from myfunc
3009 MainThread Hello from main
3013 Thread-1 Hi from myfunc
3515 Thread-1 Hi from myfunc
3761 MainThread Hello from main
4017 Thread-1 Hi from myfunc
4513 MainThread Hello from main
4518 Thread-1 Hi from myfunc
Как и следовало ожидать, вывод журнала перемежается. Разумеется, такой подход работает и для большего количества потоков, чем показано здесь.
Несколько обработчиков и форматировщиков¶Multiple handlers and formatters
Логгеры – это обычные объекты Python. У метода addHandler() нет минимального или максимального ограничения на количество добавляемых обработчиков. Иногда приложению полезно записывать все сообщения всех уровней в текстовый файл и одновременно выводить ошибки и сообщения выше в консоль. Чтобы это настроить, достаточно сконфигурировать нужные обработчики. Вызовы журналирования в коде приложения останутся без изменений. Вот небольшая модификация предыдущего простого примера конфигурации на основе модуля:
import logging
logger = logging.getLogger('simple_example')
logger.setLevel(logging.DEBUG)
# создать файловый обработчик, записывающий даже отладочные сообщения
fh = logging.FileHandler('spam.log')
fh.setLevel(logging.DEBUG)
# создать консольный обработчик с более высоким уровнем логирования
ch = logging.StreamHandler()
ch.setLevel(logging.ERROR)
# создать форматтер и добавить его к обработчикам
formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
ch.setFormatter(formatter)
fh.setFormatter(formatter)
# добавить обработчики в логгер
logger.addHandler(ch)
logger.addHandler(fh)
# код 'приложения'
logger.debug('debug message')
logger.info('info message')
logger.warning('warn message')
logger.error('error message')
logger.critical('critical message')
Обратите внимание, что «прикладной» код не заботится о нескольких обработчиках. Единственное, что изменилось – добавление и настройка нового обработчика с именем fh.
Возможность создавать новые обработчики с фильтрами более высокого или низкого уровня очень полезна при написании и тестировании приложения. Вместо множества операторов print для отладки используйте logger.debug: в отличие от операторов print, которые позже придётся удалять или закомментировать, вызовы logger.debug могут оставаться в исходном коде и оставаться неактивными, пока они снова не понадобятся. В тот момент единственное, что нужно изменить – уровень журналирования логгера и/или обработчика на DEBUG.
Журналирование в несколько мест назначения¶Logging to multiple destinations
Допустим, вы хотите вести журнал в консоль и файл с разными форматами сообщений и в разных ситуациях. Предположим, вы хотите записывать сообщения уровня DEBUG и выше в файл, а сообщения уровня INFO и выше – в консоль. Также предположим, что файл должен содержать временные метки, а консольные сообщения – нет. Вот как это можно сделать:
import logging
# настроить логирование в файл – подробнее см. предыдущий раздел
logging.basicConfig(level=logging.DEBUG,
format='%(asctime)s %(name)-12s %(levelname)-8s %(message)s',
datefmt='%m-%d %H:%M',
filename='/temp/myapp.log',
filemode='w')
# Определяет обработчик, который записывает сообщения уровня INFO и выше в sys.stderr.
console = logging.StreamHandler()
console.setLevel(logging.INFO)
# Задает формат, упрощенный для вывода в консоль.
formatter = logging.Formatter('%(name)-12s: %(levelname)-8s %(message)s')
# Указывает обработчику использовать этот формат.
console.setFormatter(formatter)
# Добавляет обработчик в корневой логгер.
logging.getLogger('').addHandler(console)
# Теперь можно выполнять запись в корневой логгер или любой другой. Сначала корневой...
logging.info('Jackdaws love my big sphinx of quartz.')
# Теперь определите несколько других логгеров, которые могут представлять разные части приложения:
# приложение:
logger1 = logging.getLogger('myapp.area1')
logger2 = logging.getLogger('myapp.area2')
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
logger1.info('How quickly daft jumping zebras vex.')
logger2.warning('Jail zesty vixen who grabbed pay from quack.')
logger2.error('The five boxing wizards jump quickly.')
При запуске на консоли вы увидите
root : INFO Jackdaws love my big sphinx of quartz.
myapp.area1 : INFO How quickly daft jumping zebras vex.
myapp.area2 : WARNING Jail zesty vixen who grabbed pay from quack.
myapp.area2 : ERROR The five boxing wizards jump quickly.
а в файле увидите примерно такое
10-22 22:19 root INFO Jackdaws love my big sphinx of quartz.
10-22 22:19 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
10-22 22:19 myapp.area1 INFO How quickly daft jumping zebras vex.
10-22 22:19 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
10-22 22:19 myapp.area2 ERROR The five boxing wizards jump quickly.
Как видите, сообщение DEBUG отображается только в файле. Остальные сообщения отправляются в оба места назначения.
В этом примере используются консольный и файловый обработчики, но вы можете использовать любое количество и любое сочетание обработчиков по своему выбору.
Пример сервера конфигурации¶Configuration server example
Вот пример модуля, использующего сервер конфигурации журналирования:
import logging
import logging.config
import time
import os
# Прочитать начальный конфигурационный файл.
logging.config.fileConfig('logging.conf')
# Создать и запустить слушатель на порту 9999.
t = logging.config.listen(9999)
t.start()
logger = logging.getLogger('simpleExample')
try:
# Прокрутить вызовы логирования, чтобы увидеть разницу.
# Создавать новые конфигурации до нажатия Ctrl+C.
while True:
logger.debug('debug message')
logger.info('info message')
logger.warning('warn message')
logger.error('error message')
logger.critical('critical message')
time.sleep(5)
except KeyboardInterrupt:
# очистка
logging.config.stopListening()
t.join()
А вот скрипт, который принимает имя файла и отправляет этот файл на сервер, предварив его двоично-закодированной длиной, в качестве новой конфигурации журналирования:
#!/usr/bin/env python
import socket, sys, struct
with open(sys.argv[1], 'rb') as f:
data_to_send = f.read()
HOST = 'localhost'
PORT = 9999
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print('connecting...')
s.connect((HOST, PORT))
print('sending config...')
s.send(struct.pack('>L', len(data_to_send)))
s.send(data_to_send)
s.close()
print('complete')
Работа с блокирующими обработчиками¶Dealing with handlers that block
Иногда требуется, чтобы обработчики логирования выполняли свою работу, не блокируя поток, из которого ведется логирование. Это часто встречается в веб-приложениях, хотя, конечно, бывает и в других сценариях.
Типичный виновник медленной работы – SMTPHandler: отправка электронной почты может занимать много времени по ряду причин, не зависящих от разработчика (например, из-за плохой работы почтовой или сетевой инфраструктуры). Но почти любой сетевой обработчик может блокировать: даже операция SocketHandler может выполнять DNS-запрос «под капотом», который оказывается слишком медленным (и этот запрос может быть глубоко в коде библиотеки сокетов, ниже уровня Python и вне вашего контроля).
Одно из решений – использовать двухчастный подход. На первом этапе к логгерам, к которым обращаются из критичных по производительности потоков, следует подключать только QueueHandler. Они просто пишут в свою очередь, которую можно настроить на достаточно большую ёмкость или инициализировать без верхнего ограничения размера. Запись в очередь обычно выполняется быстро, хотя в коде желательно перехватывать исключение queue.Full на всякий случай. Если вы – разработчик библиотеки, в коде которой есть критичные по производительности потоки, обязательно задокументируйте это (вместе с рекомендацией подключать к вашим логгерам только QueueHandlers) для пользы других разработчиков, которые будут использовать ваш код.
Вторая часть решения – QueueListener, который был разработан как аналог QueueHandler. QueueListener устроен очень просто: ему передаётся очередь и несколько обработчиков, и он запускает внутренний поток, который слушает свою очередь на предмет LogRecords, отправленных из QueueHandlers (или любого другого источника LogRecords). LogRecords извлекаются из очереди и передаются обработчикам для обработки.
Преимущество отдельного класса QueueListener в том, что один его экземпляр может обслуживать несколько QueueHandlers. Это более экономит ресурсы, чем, скажем, многопоточные версии существующих классов обработчиков, которые расходовали бы по одному потоку на обработчик без особой пользы.
Ниже приведён пример использования этих двух классов (импорты опущены):
que = queue.Queue(-1) # Без ограничения размера.
queue_handler = QueueHandler(que)
handler = logging.StreamHandler()
listener = QueueListener(que, handler)
root = logging.getLogger()
root.addHandler(queue_handler)
formatter = logging.Formatter('%(threadName)s: %(message)s')
handler.setFormatter(formatter)
listener.start()
# Вывод лога будет отображать поток, создавший событие (главный поток), а не внутренний поток,
# отслеживающий внутреннюю очередь.
# Именно это и должно происходить.
# то, что должно произойти.
root.warning('Look out!')
listener.stop()
который при запуске выведет:
MainThread: Look out!
Изменено в версии 3.5: До Python 3.5 QueueListener всегда передавал каждое полученное из очереди сообщение каждому обработчику, с которыми был инициализирован. (Это объяснялось тем, что предполагалось, что фильтрация по уровню полностью выполняется на стороне наполнения очереди.) Начиная с версии 3.5 это поведение можно изменить, передав именованный аргумент respect_handler_level=True конструктору слушателя. Когда это сделано, слушатель сравнивает уровень каждого сообщения с уровнем обработчика и передаёт сообщение обработчику, только если это уместно.
Отправка и получение событий логирования по сети¶Sending and receiving logging events across a network
Допустим, вы хотите отправлять события логирования по сети и обрабатывать их на принимающей стороне. Простой способ – подключить экземпляр SocketHandler к корневому логгеру на отправляющей стороне:
import logging, logging.handlers
rootLogger = logging.getLogger('')
rootLogger.setLevel(logging.DEBUG)
socketHandler = logging.handlers.SocketHandler('localhost',
logging.handlers.DEFAULT_TCP_LOGGING_PORT)
# Не нужно использовать форматтер, так как сокет-обработчик отправляет событие в виде неформатированного пикла.
# неформатированный pickle
rootLogger.addHandler(socketHandler)
# Теперь можно выполнять запись в корневой логгер или любой другой. Сначала корневой...
logging.info('Jackdaws love my big sphinx of quartz.')
# Теперь определите несколько других логгеров, которые могут представлять разные части приложения:
# приложение:
logger1 = logging.getLogger('myapp.area1')
logger2 = logging.getLogger('myapp.area2')
logger1.debug('Quick zephyrs blow, vexing daft Jim.')
logger1.info('How quickly daft jumping zebras vex.')
logger2.warning('Jail zesty vixen who grabbed pay from quack.')
logger2.error('The five boxing wizards jump quickly.')
На принимающей стороне можно настроить приёмник с помощью модуля socketserver. Вот простой работающий пример:
import pickle
import logging
import logging.handlers
import socketserver
import struct
class LogRecordStreamHandler(socketserver.StreamRequestHandler):
"""Обработчик для потокового запроса логирования.
Это по сути записывает запись, используя ту политику логирования, которая настроена локально.
настроено локально.
"""
def handle(self):
"""
Обрабатывает несколько запросов – каждый ожидается в формате: 4-байтовая длина, затем запись журнала в формате пикл.
Записывает запись в соответствии с политикой, настроенной локально.
согласно локально настроенной политике.
"""
while True:
chunk = self.connection.recv(4)
if len(chunk) < 4:
break
slen = struct.unpack('>L', chunk)[0]
chunk = self.connection.recv(slen)
while len(chunk) < slen:
chunk = chunk + self.connection.recv(slen - len(chunk))
obj = self.unPickle(chunk)
record = logging.makeLogRecord(obj)
self.handleLogRecord(record)
def unPickle(self, data):
return pickle.loads(data)
def handleLogRecord(self, record):
# Если указано имя, используется именованный логгер, а не тот, что
# подразумевается записью.
if self.server.logname is not None:
name = self.server.logname
else:
name = record.name
logger = logging.getLogger(name)
# Примечание: КАЖДАЯ запись попадает в журнал. Это связано с тем, что Logger.handle
# обычно вызывается ПОСЛЕ фильтрации на уровне регистратора. Если требуется
# выполнять фильтрацию, делайте это на стороне клиента, чтобы не тратить
# циклы процессора и сетевую пропускную способность!
logger.handle(record)
class LogRecordSocketReceiver(socketserver.ThreadingTCPServer):
"""
Простой приёмник журнала на основе TCP-сокетов, подходящий для тестирования.
"""
allow_reuse_address = True
def __init__(self, host='localhost',
port=logging.handlers.DEFAULT_TCP_LOGGING_PORT,
handler=LogRecordStreamHandler):
socketserver.ThreadingTCPServer.__init__(self, (host, port), handler)
self.abort = 0
self.timeout = 1
self.logname = None
def serve_until_stopped(self):
import select
abort = 0
while not abort:
rd, wr, ex = select.select([self.socket.fileno()],
[], [],
self.timeout)
if rd:
self.handle_request()
abort = self.abort
def main():
logging.basicConfig(
format='%(relativeCreated)5d %(name)-15s %(levelname)-8s %(message)s')
tcpserver = LogRecordSocketReceiver()
print('About to start TCP server...')
tcpserver.serve_until_stopped()
if __name__ == '__main__':
main()
Сначала запустите сервер, затем клиент. На стороне клиента в консоль ничего не выводится; на стороне сервера вы должны увидеть что-то вроде:
About to start TCP server...
59 root INFO Jackdaws love my big sphinx of quartz.
59 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
69 myapp.area1 INFO How quickly daft jumping zebras vex.
69 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
69 myapp.area2 ERROR The five boxing wizards jump quickly.
Обратите внимание, что в некоторых сценариях существуют проблемы безопасности с pickle. Если они вас затрагивают, вы можете использовать альтернативную схему сериализации, переопределив метод makePickle() и реализовав свою альтернативу там, а также адаптировав вышеприведённый скрипт для использования вашей альтернативной сериализации.
Добавление контекстной информации в вывод журнала¶Adding contextual information to your logging output
Иногда требуется, чтобы вывод журнала содержал контекстную информацию в
дополнение к параметрам, переданным в вызове логирования. Например, в
сетевом приложении может быть желательно записывать в журнал информацию, специфичную для клиента
(например, имя пользователя удалённого клиента или IP-адрес). Хотя для этого можно использовать
параметр extra, не всегда удобно передавать
информацию таким образом. Может возникнуть соблазн создавать
экземпляры Logger для каждого соединения, но это плохая идея,
поскольку такие экземпляры не собираются сборщиком мусора. Хотя на практике это не проблема,
когда количество экземпляров Logger зависит от
уровня детализации, используемого при логировании приложения, управление ими может
стать сложным, если количество экземпляров Logger станет
фактически неограниченным.
Использование LoggerAdapter для добавления контекстной информации¶Using LoggerAdapters to impart contextual information
Простой способ передавать контекстную информацию для вывода вместе
с информацией о событиях логирования – использовать класс LoggerAdapter.
Этот класс спроектирован так, чтобы выглядеть как Logger, что позволяет вызывать
debug(), info(), warning(), error(),
exception(), critical() и log(). Эти методы имеют те же
сигнатуры, что и их аналоги в Logger, поэтому экземпляры обоих типов
можно использовать взаимозаменяемо.
При создании экземпляра LoggerAdapter вы передаёте ему
экземпляр Logger и объект, подобный словарю, содержащий вашу контекстную
информацию. Когда вы вызываете один из методов логирования на экземпляре
LoggerAdapter, он делегирует вызов базовому экземпляру
Logger, переданному в конструктор, и организует передачу контекстной
информации в этом делегированном вызове. Вот фрагмент кода
LoggerAdapter:
def debug(self, msg, /, *args, **kwargs):
"""
Передаёт вызов отладки нижележащему регистратору после добавления
контекстной информации из данного экземпляра адаптера.
"""
msg, kwargs = self.process(msg, kwargs)
self.logger.debug(msg, *args, **kwargs)
Метод process() класса LoggerAdapter – это то место, где
контекстная информация добавляется в вывод журнала. Ему передаются сообщение
и именованные аргументы вызова логирования, а он возвращает (потенциально)
изменённые версии для использования в вызове базового регистратора. В
реализации по умолчанию этот метод оставляет сообщение без изменений, но
вставляет ключ 'extra' в именованные аргументы, значением которого является объект, подобный словарю,
переданный конструктору. Конечно, если вы передали именованный аргумент 'extra'
в вызове адаптера, он будет молча перезаписан.
Преимущество использования 'extra' в том, что значения из объекта, подобного словарю,
сливаются в __dict__ экземпляра LogRecord, что позволяет использовать
настроенные строки с экземплярами Formatter, которые знают о
ключах этого объекта. Если вам нужен другой метод, например, добавить
контекстную информацию в начало или конец строки сообщения,
достаточно создать подкласс LoggerAdapter и переопределить
process() для нужного поведения. Вот простой пример:
class CustomAdapter(logging.LoggerAdapter):
"""
Данный пример адаптера ожидает, что переданный объект, подобный словарю, содержит
ключ 'connid', значение которого в квадратных скобках добавляется к началу сообщения журнала.
"""
def process(self, msg, kwargs):
return '[%s] %s' % (self.extra['connid'], msg), kwargs
который можно использовать так:
logger = logging.getLogger(__name__)
adapter = CustomAdapter(logger, {'connid': some_conn_id})
Тогда все события, регистрируемые через адаптер, будут содержать значение
some_conn_id, добавленное в начало сообщений журнала.
Использование объектов, отличных от словарей, для передачи контекстной информации¶Using objects other than dicts to pass contextual information
Необязательно передавать в LoggerAdapter именно словарь – можно
передать экземпляр класса, реализующего __getitem__ и __iter__, чтобы
он выглядел как словарь для системы логирования. Это полезно, если нужно
генерировать значения динамически (тогда как значения в словаре были бы постоянными).
Использование фильтров для добавления контекстной информации¶Using Filters to impart contextual information
Вы также можете добавлять контекстную информацию в вывод журнала с помощью определённого пользователем
Filter. Экземплярам Filter разрешено изменять LogRecords,
переданный им, включая добавление дополнительных атрибутов, которые затем можно выводить
с помощью подходящей форматной строки или, если необходимо, пользовательского Formatter.
Например, в веб-приложении обрабатываемый запрос (или, по крайней мере,
его интересные части) можно сохранить в потоковой локальной переменной
(threading.local), а затем из Filter получить к ней доступ, чтобы
добавить, скажем, информацию из запроса – например, удалённый IP-адрес и имя
пользователя – в LogRecord, используя имена атрибутов 'ip' и
'user', как в примере с LoggerAdapter выше. В этом случае можно использовать ту же
форматную строку для получения вывода, аналогичного показанному выше. Вот пример
скрипта:
import logging
from random import choice
class ContextFilter(logging.Filter):
"""
Это фильтр, который внедряет контекстную информацию в журнал.
Вместо использования реальной контекстной информации в данном примере используются случайные
данные.
"""
USERS = ['jim', 'fred', 'sheila']
IPS = ['123.231.231.123', '127.0.0.1', '192.168.0.1']
def filter(self, record):
record.ip = choice(ContextFilter.IPS)
record.user = choice(ContextFilter.USERS)
return True
if __name__ == '__main__':
levels = (logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR, logging.CRITICAL)
logging.basicConfig(level=logging.DEBUG,
format='%(asctime)-15s %(name)-5s %(levelname)-8s IP: %(ip)-15s User: %(user)-8s %(message)s')
a1 = logging.getLogger('a.b.c')
a2 = logging.getLogger('d.e.f')
f = ContextFilter()
a1.addFilter(f)
a2.addFilter(f)
a1.debug('A debug message')
a1.info('An info message with %s', 'some parameters')
for x in range(10):
lvl = choice(levels)
lvlname = logging.getLevelName(lvl)
a2.log(lvl, 'A message at %s level with %d %s', lvlname, 2, 'parameters')
который при запуске выдаёт примерно следующее:
2010-09-06 22:38:15,292 a.b.c DEBUG IP: 123.231.231.123 User: fred A debug message
2010-09-06 22:38:15,300 a.b.c INFO IP: 192.168.0.1 User: sheila An info message with some parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 127.0.0.1 User: sheila A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f ERROR IP: 127.0.0.1 User: jim A message at ERROR level with 2 parameters
2010-09-06 22:38:15,300 d.e.f DEBUG IP: 127.0.0.1 User: sheila A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,300 d.e.f ERROR IP: 123.231.231.123 User: fred A message at ERROR level with 2 parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 192.168.0.1 User: jim A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f CRITICAL IP: 127.0.0.1 User: sheila A message at CRITICAL level with 2 parameters
2010-09-06 22:38:15,300 d.e.f DEBUG IP: 192.168.0.1 User: jim A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,301 d.e.f ERROR IP: 127.0.0.1 User: sheila A message at ERROR level with 2 parameters
2010-09-06 22:38:15,301 d.e.f DEBUG IP: 123.231.231.123 User: fred A message at DEBUG level with 2 parameters
2010-09-06 22:38:15,301 d.e.f INFO IP: 123.231.231.123 User: fred A message at INFO level with 2 parameters
Ведение журнала в один файл из нескольких процессов¶Logging to a single file from multiple processes
Хотя модуль logging является потокобезопасным и запись в один файл из нескольких потоков в одном процессе поддерживается, запись в один файл из нескольких процессов не поддерживается, поскольку в Python нет стандартного способа сериализовать доступ к одному файлу из нескольких процессов. Если нужно вести журнал в один файл из нескольких процессов, один из способов – сделать так, чтобы все процессы записывали данные в SocketHandler, а отдельный процесс реализовывал сокет-сервер, который читает из сокета и записывает в файл. (Если хотите, можно выделить один поток в одном из существующих процессов для выполнения этой функции.) В этом разделе подробно описывается данный подход и приводится рабочий приёмник сокета, который можно использовать как отправную точку для адаптации в своих приложениях.
Вы также можете написать собственный обработчик, который использует класс Lock
из модуля multiprocessing для сериализации доступа к
файлу из ваших процессов. Существующие FileHandler и подклассы в настоящее время
не используют multiprocessing, хотя в будущем они могут это сделать.
Обратите внимание, что в настоящее время модуль multiprocessing не обеспечивает
рабочую функциональность блокировки на всех платформах (см.
https://bugs.python.org/issue3770).
В качестве альтернативы можно использовать Queue и QueueHandler для отправки всех событий журналирования одному из процессов в вашем многопроцессном приложении. В следующем примере сценария показано, как это сделать; в примере отдельный процесс-слушатель ожидает события, отправленные другими процессами, и регистрирует их в соответствии со своей собственной конфигурацией журналирования. Хотя пример демонстрирует лишь один из способов (например, вместо отдельного процесса-слушателя можно использовать поток-слушатель – реализация будет аналогичной), он позволяет задать полностью разные конфигурации журналирования для слушателя и остальных процессов в вашем приложении и может быть использован как основа для кода, отвечающего вашим конкретным требованиям:
# Вам понадобятся эти импорты в вашем коде.
import logging
import logging.handlers
import multiprocessing
# Следующие две строки импорта только для этой демонстрации.
from random import choice, random
import time
#
# Поскольку нужно задать настройки логирования для слушателя и рабочих процессов, функции
# слушателя и рабочего процесса принимают параметр configurer – вызываемый объект для
# настройки логирования этого процесса. Эти функции также получают очередь, которую
# используют для взаимодействия.
#
# На практике слушателя можно настроить как угодно, но заметьте: в этом простом
# примере слушатель не применяет логику уровней или фильтров к полученным записям.
# На практике эту логику, вероятно, стоит вынести в рабочие процессы, чтобы не
# пересылать между процессами события, которые всё равно будут отфильтрованы.
#
# Размер файлов при ротации намеренно сделан небольшим, чтобы результат был хорошо виден.
def listener_configurer():
root = logging.getLogger()
h = logging.handlers.RotatingFileHandler('mptest.log', 'a', 300, 10)
f = logging.Formatter('%(asctime)s %(processName)-10s %(name)s %(levelname)-8s %(message)s')
h.setFormatter(f)
root.addHandler(h)
# Это главный цикл процесса-слушателя: ждём события логирования
# (LogRecords) в очереди и обрабатываем их; завершаем работу, когда получаем None вместо
# LogRecord.
def listener_process(queue, configurer):
configurer()
while True:
try:
record = queue.get()
if record is None: # Отправляем это как сигнал завершения, чтобы слушатель остановился.
break
logger = logging.getLogger(record.name)
logger.handle(record) # Никакой логики уровней и фильтров – просто делаем дело!
except Exception:
import sys, traceback
print('Whoops! Problem:', file=sys.stderr)
traceback.print_exc(file=sys.stderr)
# Массивы для случайного выбора в этой демонстрации.
LEVELS = [logging.DEBUG, logging.INFO, logging.WARNING,
logging.ERROR, logging.CRITICAL]
LOGGERS = ['a.b.c', 'd.e.f']
MESSAGES = [
'Random message #1',
'Random message #2',
'Random message #3',
]
# Настройка рабочего процесса выполняется в начале его работы.
# Обратите внимание: в Windows нельзя полагаться на семантику fork, поэтому каждый процесс
# будет выполнять код настройки логирования при запуске.
def worker_configurer(queue):
h = logging.handlers.QueueHandler(queue) # Нужен только один обработчик.
root = logging.getLogger()
root.addHandler(h)
# Отправляем все сообщения для демонстрации; никакой другой логики уровней или фильтров.
root.setLevel(logging.DEBUG)
# Это главный цикл рабочего процесса, который просто логирует десять событий с
# случайные задержки перед завершением.
# Сообщения print нужны лишь для того, чтобы было видно, что программа работает.
def worker_process(queue, configurer):
configurer(queue)
name = multiprocessing.current_process().name
print('Worker started: %s' % name)
for i in range(10):
time.sleep(random())
logger = logging.getLogger(choice(LOGGERS))
level = choice(LEVELS)
message = choice(MESSAGES)
logger.log(level, message)
print('Worker finished: %s' % name)
# Здесь организуется демонстрация. Создать очередь, создать и запустить
# слушатель, создать десять рабочих процессов и запустить их, дождаться их завершения,
# затем отправить None в очередь, чтобы сообщить слушателю о завершении.
def main():
queue = multiprocessing.Queue(-1)
listener = multiprocessing.Process(target=listener_process,
args=(queue, listener_configurer))
listener.start()
workers = []
for i in range(10):
worker = multiprocessing.Process(target=worker_process,
args=(queue, worker_configurer))
workers.append(worker)
worker.start()
for w in workers:
w.join()
queue.put_nowait(None)
listener.join()
if __name__ == '__main__':
main()
Вариант приведённого выше сценария оставляет ведение журнала в главном процессе, в отдельном потоке:
import logging
import logging.config
import logging.handlers
from multiprocessing import Process, Queue
import random
import threading
import time
def logger_thread(q):
while True:
record = q.get()
if record is None:
break
logger = logging.getLogger(record.name)
logger.handle(record)
def worker_process(q):
qh = logging.handlers.QueueHandler(q)
root = logging.getLogger()
root.setLevel(logging.DEBUG)
root.addHandler(qh)
levels = [logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR,
logging.CRITICAL]
loggers = ['foo', 'foo.bar', 'foo.bar.baz',
'spam', 'spam.ham', 'spam.ham.eggs']
for i in range(100):
lvl = random.choice(levels)
logger = logging.getLogger(random.choice(loggers))
logger.log(lvl, 'Message no. %d', i)
if __name__ == '__main__':
q = Queue()
d = {
'version': 1,
'formatters': {
'detailed': {
'class': 'logging.Formatter',
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
}
},
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'level': 'INFO',
},
'file': {
'class': 'logging.FileHandler',
'filename': 'mplog.log',
'mode': 'w',
'formatter': 'detailed',
},
'foofile': {
'class': 'logging.FileHandler',
'filename': 'mplog-foo.log',
'mode': 'w',
'formatter': 'detailed',
},
'errors': {
'class': 'logging.FileHandler',
'filename': 'mplog-errors.log',
'mode': 'w',
'level': 'ERROR',
'formatter': 'detailed',
},
},
'loggers': {
'foo': {
'handlers': ['foofile']
}
},
'root': {
'level': 'DEBUG',
'handlers': ['console', 'file', 'errors']
},
}
workers = []
for i in range(5):
wp = Process(target=worker_process, name='worker %d' % (i + 1), args=(q,))
workers.append(wp)
wp.start()
logging.config.dictConfig(d)
lp = threading.Thread(target=logger_thread, args=(q,))
lp.start()
# На этом этапе главный процесс может заняться своей полезной работой
# Когда он с этим закончит, он может дождаться завершения рабочих процессов...
for wp in workers:
wp.join()
# А теперь указать потоку журналирования завершиться
q.put(None)
lp.join()
Этот вариант показывает, как можно, например, применить конфигурацию для определённых регистраторов – например, регистратор foo имеет специальный обработчик, который сохраняет все события подсистемы foo в файл mplog-foo.log. Это будет использовано механизмом журналирования в главном процессе (даже если события журналирования генерируются в рабочих процессах) для направления сообщений к соответствующим местам назначения.
Использование concurrent.futures.ProcessPoolExecutor¶Using concurrent.futures.ProcessPoolExecutor
Если вы хотите использовать concurrent.futures.ProcessPoolExecutor для запуска рабочих процессов, необходимо создать очередь немного иначе. Вместо
queue = multiprocessing.Queue(-1)
следует использовать
queue = multiprocessing.Manager().Queue(-1) # также работает с примерами выше
и затем можно заменить создание рабочего процесса с этого:
workers = []
for i in range(10):
worker = multiprocessing.Process(target=worker_process,
args=(queue, worker_configurer))
workers.append(worker)
worker.start()
for w in workers:
w.join()
на это (не забудьте сначала импортировать concurrent.futures):
with concurrent.futures.ProcessPoolExecutor(max_workers=10) as executor:
for i in range(10):
executor.submit(worker_process, queue, worker_configurer)
Использование ротации файлов¶Using file rotation
Иногда требуется позволить файлу журнала расти до определённого размера, затем открыть новый файл и вести запись в него. Может потребоваться сохранять определённое количество таких файлов, и когда будет создано заданное число файлов, выполнять ротацию, чтобы и количество, и размер файлов оставались в заданных границах. Для такого сценария использования пакет logging предоставляет RotatingFileHandler:
import glob
import logging
import logging.handlers
LOG_FILENAME = 'logging_rotatingfile_example.out'
# Настроить конкретный регистратор с нужным уровнем вывода
my_logger = logging.getLogger('MyLogger')
my_logger.setLevel(logging.DEBUG)
# Добавить обработчик сообщений журнала в регистратор
handler = logging.handlers.RotatingFileHandler(
LOG_FILENAME, maxBytes=20, backupCount=5)
my_logger.addHandler(handler)
# Записать несколько сообщений
for i in range(20):
my_logger.debug('i = %d' % i)
# Посмотреть, какие файлы созданы
logfiles = glob.glob('%s*' % LOG_FILENAME)
for filename in logfiles:
print(filename)
В результате должно получиться 6 отдельных файлов, каждый из которых содержит часть истории журнала приложения:
logging_rotatingfile_example.out
logging_rotatingfile_example.out.1
logging_rotatingfile_example.out.2
logging_rotatingfile_example.out.3
logging_rotatingfile_example.out.4
logging_rotatingfile_example.out.5
Самый свежий файл всегда называется logging_rotatingfile_example.out, и каждый раз при достижении ограничения по размеру он переименовывается с суффиксом .1. Каждый из существующих резервных файлов переименовывается с увеличением суффикса (.1 становится .2 и т.д.), а файл .6 удаляется.
Разумеется, в этом примере размер файла журнала установлен слишком маленьким для наглядности. В реальности нужно установить maxBytes в подходящее значение.
Использование альтернативных стилей форматирования¶Use of alternative formatting styles
Когда журналирование было добавлено в стандартную библиотеку Python, единственным способом форматирования сообщений с переменным содержимым было использование %-форматирования. С тех пор в Python появились два новых подхода к форматированию: string.Template (добавлен в Python 2.4) и str.format() (добавлен в Python 2.6).
Начиная с версии 3.2, модуль logging предоставляет улучшенную поддержку этих двух дополнительных стилей форматирования. Класс Formatter был расширен: добавлен дополнительный необязательный именованный параметр style. По умолчанию он равен '%', но возможны также значения '{' и '$', соответствующие двум другим стилям форматирования. Обратная совместимость сохраняется по умолчанию (как и следовало ожидать), но при явном указании параметра style появляется возможность задавать строки формата, работающие с str.format() или string.Template. Вот пример сеанса работы в консоли, демонстрирующий возможности:
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel(logging.DEBUG)
>>> handler = logging.StreamHandler()
>>> bf = logging.Formatter('{asctime} {name} {levelname:8s} {message}',
... style='{')
>>> handler.setFormatter(bf)
>>> root.addHandler(handler)
>>> logger = logging.getLogger('foo.bar')
>>> logger.debug('This is a DEBUG message')
2010-10-28 15:11:55,341 foo.bar DEBUG This is a DEBUG message
>>> logger.critical('This is a CRITICAL message')
2010-10-28 15:12:11,526 foo.bar CRITICAL This is a CRITICAL message
>>> df = logging.Formatter('$asctime $name ${levelname} $message',
... style='$')
>>> handler.setFormatter(df)
>>> logger.debug('This is a DEBUG message')
2010-10-28 15:13:06,924 foo.bar DEBUG This is a DEBUG message
>>> logger.critical('This is a CRITICAL message')
2010-10-28 15:13:11,494 foo.bar CRITICAL This is a CRITICAL message
>>>
Обратите внимание: форматирование сообщений журнала для конечного вывода в файлы совершенно не зависит от того, как конструируется отдельное сообщение. Оно по-прежнему может использовать %-форматирование, как показано ниже:
>>> logger.error('This is an%s %s %s', 'other,', 'ERROR,', 'message')
2010-10-28 15:19:29,833 foo.bar ERROR This is another, ERROR, message
>>>
Вызовы функций журналирования (logger.debug(), logger.info() и т.д.) принимают только позиционные параметры для самого сообщения журнала; именованные параметры используются только для определения параметров обработки вызова (например, именованный параметр exc_info указывает, что нужно записать информацию о трассировке стека, или именованный параметр extra – добавить дополнительный контекст в журнал). Поэтому невозможно напрямую использовать синтаксис str.format() или string.Template при вызовах, поскольку внутри пакет logging использует %-форматирование для объединения строки формата и переменных аргументов. Изменить это без нарушения обратной совместимости нельзя, так как все существующие вызовы logging в существующем коде используют %-формат строк.
Однако существует способ использовать {}- и $-форматирование для построения отдельных сообщений журнала. Напомним, что в качестве строки формата сообщения можно использовать произвольный объект, и пакет logging вызовет у этого объекта str() для получения фактической строки формата. Рассмотрим следующие два класса:
class BraceMessage:
def __init__(self, fmt, /, *args, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs
def __str__(self):
return self.fmt.format(*self.args, **self.kwargs)
class DollarMessage:
def __init__(self, fmt, /, **kwargs):
self.fmt = fmt
self.kwargs = kwargs
def __str__(self):
from string import Template
return Template(self.fmt).substitute(**self.kwargs)
Любой из этих классов можно использовать вместо строки формата, чтобы разрешить применение {}- или $-форматирования для построения фактической части «message», которая появляется в отформатированном выводе журнала вместо «%(message)s», «{message}» или «$message». Это немного громоздко – использовать имена классов каждый раз при журналировании, но вполне приемлемо, если применить псевдоним, например __ (двойное подчеркивание – не путать с _, одинарным подчеркиванием, используемым как синоним/псевдоним для gettext.gettext() или его аналогов).
Вышеуказанные классы не входят в состав Python, но их легко скопировать и вставить в свой код. Их можно использовать следующим образом (предполагая, что они объявлены в модуле с именем wherever):
>>> from wherever import BraceMessage as __
>>> print(__('Message with {0} {name}', 2, name='placeholders'))
Message with 2 placeholders
>>> class Point: pass
...
>>> p = Point()
>>> p.x = 0.5
>>> p.y = 0.5
>>> print(__('Message with coordinates: ({point.x:.2f}, {point.y:.2f})',
... point=p))
Message with coordinates: (0.50, 0.50)
>>> from wherever import DollarMessage as __
>>> print(__('Message with $num $what', num=2, what='placeholders'))
Message with 2 placeholders
>>>
Хотя в приведённых выше примерах используется print() для демонстрации работы форматирования, в реальности для ведения журнала с помощью этого подхода следует использовать logger.debug() или аналогичную функцию.
Следует отметить, что этот подход не даёт значительного снижения производительности с этим подходом: фактическое форматирование происходит не тогда, когда вы делаете вызов регистрации, а когда (и если) регистрируемое сообщение действительно должно быть выведено в журнал с помощью обработчика. Поэтому единственное, что может сбить с толку, – это то, что скобки ставятся вокруг строки формата и аргументов, а не только вокруг строки формата. Это потому, что нотация __ – это просто синтаксический сахар для вызова конструктора одного из классов XXXMessage.
Если хотите, можно использовать LoggerAdapter для достижения аналогичного эффекта, как в следующем примере:
import logging
class Message:
def __init__(self, fmt, args):
self.fmt = fmt
self.args = args
def __str__(self):
return self.fmt.format(*self.args)
class StyleAdapter(logging.LoggerAdapter):
def __init__(self, logger, extra=None):
super().__init__(logger, extra or {})
def log(self, level, msg, /, *args, **kwargs):
if self.isEnabledFor(level):
msg, kwargs = self.process(msg, kwargs)
self.logger._log(level, Message(msg, args), (), **kwargs)
logger = StyleAdapter(logging.getLogger(__name__))
def main():
logger.debug('Hello, {}', 'world!')
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG)
main()
При запуске с
Python 3.2 или новее указанный выше скрипт должен записать сообщение Hello, world!.
Настройка LogRecord¶Customizing LogRecord
Каждое событие журналирования представлено экземпляром LogRecord. Когда событие регистрируется и не отфильтровывается по уровню регистратора, создаётся LogRecord, заполняется информацией о событии и затем передаётся обработчикам для этого регистратора (и его предков, вплоть до регистратора, в котором дальнейшее распространение по иерархии отключено). До Python 3.2 было только два места, где выполнялось это создание:
Logger.makeRecord(), который вызывается в обычном процессе регистрации события. Он напрямую вызывалLogRecordдля создания экземпляра.makeLogRecord(), которая вызывается со словарем, содержащим атрибуты для добавления в LogRecord. Обычно она вызывается, когда подходящий словарь был получен по сети (например, в виде pickle черезSocketHandlerили в формате JSON черезHTTPHandler).
Обычно это означало, что если требуется выполнить какие-либо специальные действия с LogRecord, приходилось делать одно из следующего.
Создать собственный подкласс
Logger, который переопределяетLogger.makeRecord(), и установить его с помощьюsetLoggerClass()до того, как будут созданы какие-либо логгеры, которые вас интересуют.Добавить
Filterк логгеру или обработчику, который выполняет необходимые специальные манипуляции при вызове его методаfilter().
Первый подход был бы несколько громоздким в сценарии, где (скажем) несколько разных библиотек хотели бы делать разные вещи. Каждая попыталась бы установить свой собственный подкласс Logger, и та, которая сделала это последней, победила бы.
Второй подход достаточно хорошо работает во многих случаях, но не позволяет, например, использовать специализированный подкласс LogRecord. Разработчики библиотек могут установить подходящий фильтр на своих логгерах, но им приходилось бы помнить об этом каждый раз, когда они добавляют новый логгер (что они делают, просто добавляя новые пакеты или модули и выполняя
logger = logging.getLogger(__name__)
на уровне модуля). Вероятно, это одна из тех вещей, о которых нужно помнить. Разработчики также могли бы добавить фильтр к NullHandler, прикрепленному к их корневому логгеру, но он не будет вызываться, если разработчик приложения прикрепит обработчик к логгеру библиотеки нижнего уровня – так что вывод от этого обработчика не будет отражать намерений разработчика библиотеки.
В Python 3.2 и новее создание LogRecord осуществляется через фабрику, которую можно указать. Фабрика – это просто вызываемый объект, который можно установить с помощью setLogRecordFactory() и запросить с помощью getLogRecordFactory(). Фабрика вызывается с той же сигнатурой, что и конструктор LogRecord, поскольку LogRecord является значением по умолчанию для фабрики.
Этот подход позволяет пользовательской фабрике контролировать все аспекты создания LogRecord. Например, можно вернуть подкласс или просто добавить несколько дополнительных атрибутов к записи после ее создания, используя шаблон, подобный следующему:
old_factory = logging.getLogRecordFactory()
def record_factory(*args, **kwargs):
record = old_factory(*args, **kwargs)
record.custom_attribute = 0xdecafbad
return record
logging.setLogRecordFactory(record_factory)
Этот шаблон позволяет разным библиотекам объединять фабрики в цепочку, и пока они не перезаписывают атрибуты друг друга или случайно не перезаписывают стандартные атрибуты, никаких сюрпризов быть не должно. Однако следует иметь в виду, что каждое звено цепочки добавляет накладные расходы во время выполнения ко всем операциям логирования, и эту технику следует использовать только тогда, когда использование Filter не дает желаемого результата.
Создание подкласса QueueHandler – пример с ZeroMQ¶Subclassing QueueHandler - a ZeroMQ example
Можно использовать подкласс QueueHandler для отправки сообщений в очереди других типов, например, в сокет ZeroMQ «publish». В приведенном ниже примере сокет создается отдельно и передается обработчику (в качестве его «очереди»):
import zmq # с использованием pyzmq, привязки Python к ZeroMQ
import json # для переносимой сериализации записей
ctx = zmq.Context()
sock = zmq.Socket(ctx, zmq.PUB) # или zmq.PUSH, или другое подходящее значение
sock.bind('tcp://*:5556') # или где угодно
class ZeroMQSocketHandler(QueueHandler):
def enqueue(self, record):
self.queue.send_json(record.__dict__)
handler = ZeroMQSocketHandler(sock)
Конечно, есть и другие способы организации этого, например, передача данных, необходимых обработчику для создания сокета:
class ZeroMQSocketHandler(QueueHandler):
def __init__(self, uri, socktype=zmq.PUB, ctx=None):
self.ctx = ctx or zmq.Context()
socket = zmq.Socket(self.ctx, socktype)
socket.bind(uri)
super().__init__(socket)
def enqueue(self, record):
self.queue.send_json(record.__dict__)
def close(self):
self.queue.close()
Создание подкласса QueueListener – пример с ZeroMQ¶Subclassing QueueListener - a ZeroMQ example
Можно также создать подкласс QueueListener для получения сообщений из очередей других типов, например, из сокета ZeroMQ «subscribe». Вот пример:
class ZeroMQSocketListener(QueueListener):
def __init__(self, uri, /, *handlers, **kwargs):
self.ctx = kwargs.get('ctx') or zmq.Context()
socket = zmq.Socket(self.ctx, zmq.SUB)
socket.setsockopt_string(zmq.SUBSCRIBE, '') # подписаться на всё
socket.connect(uri)
super().__init__(socket, *handlers, **kwargs)
def dequeue(self):
msg = self.queue.recv_json()
return logging.makeLogRecord(msg)
См. также
- Модуль
logging Справочник API для модуля logging.
- Модуль
logging.config API конфигурации для модуля logging.
- Модуль
logging.handlers Полезные обработчики, входящие в состав модуля logging.
Пример конфигурации на основе словаря¶An example dictionary-based configuration
Ниже приведен пример словаря конфигурации логирования – он взят из документации проекта Django. Этот словарь передается в dictConfig() для применения конфигурации:
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
},
'simple': {
'format': '%(levelname)s %(message)s'
},
},
'filters': {
'special': {
'()': 'project.logging.SpecialFilter',
'foo': 'bar',
}
},
'handlers': {
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'simple'
},
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
'filters': ['special']
}
},
'loggers': {
'django': {
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': False,
},
'myproject.custom': {
'handlers': ['console', 'mail_admins'],
'level': 'INFO',
'filters': ['special']
}
}
}
Для получения дополнительной информации об этой конфигурации можно обратиться к соответствующему разделу документации Django.
Использование ротатора и средства именования для настройки обработки ротации журналов¶Using a rotator and namer to customize log rotation processing
Пример того, как можно определить namer и rotator, приведен в следующем фрагменте кода, который демонстрирует сжатие журнала с использованием zlib:
def namer(name):
return name + ".gz"
def rotator(source, dest):
with open(source, "rb") as sf:
data = sf.read()
compressed = zlib.compress(data, 9)
with open(dest, "wb") as df:
df.write(compressed)
os.remove(source)
rh = logging.handlers.RotatingFileHandler(...)
rh.rotator = rotator
rh.namer = namer
Это не «настоящие» .gz-файлы, поскольку они представляют собой просто сжатые данные без «контейнера», который присутствует в обычном gzip-файле. Данный фрагмент приведен только для иллюстрации.
Более сложный пример с многопроцессностью¶A more elaborate multiprocessing example
Следующий рабочий пример показывает, как можно использовать логирование с многопроцессностью с помощью файлов конфигурации. Конфигурации довольно просты, но служат иллюстрацией того, как можно реализовать более сложные в реальном сценарии многопроцессной обработки.
В примере главный процесс порождает процесс-слушатель и несколько рабочих процессов. Каждый из главного процесса, слушателя и рабочих имеет три отдельные конфигурации (все рабочие используют одну и ту же конфигурацию). Видно ведение журнала в главном процессе, как рабочие пишут в QueueHandler, а слушатель реализует QueueListener и более сложную конфигурацию ведения журнала, и организует отправку событий, полученных через очередь, обработчикам, указанным в конфигурации. Обратите внимание, что эти конфигурации чисто иллюстративные, но этот пример можно адаптировать под свой сценарий.
Вот скрипт – строки документации и комментарии, надеюсь, поясняют, как он работает:
import logging
import logging.config
import logging.handlers
from multiprocessing import Process, Queue, Event, current_process
import os
import random
import time
class MyHandler:
"""
Простой обработчик для событий логирования. Он выполняется в процессе-слушателе и
распределяет события по логгерам на основе имени в полученной записи,
которые затем передаются системой логирования обработчикам,
настроенным для этих логгеров.
"""
def handle(self, record):
if record.name == "root":
logger = logging.getLogger()
else:
logger = logging.getLogger(record.name)
if logger.isEnabledFor(record.levelno):
# Имя процесса преобразуется только для того, чтобы показать, что это слушатель
# выполняет логирование в файлы и консоль.
record.processName = '%s (for %s)' % (current_process().name, record.processName)
logger.handle(record)
def listener_process(q, stop_event, config):
"""
Это можно было бы сделать в главном процессе, но сделано в отдельном
процессе для наглядности.
Это инициализирует логирование согласно указанной конфигурации
запускает слушатель и ожидает сигнала от главного процесса о завершении
через событие. Затем слушатель останавливается, и процесс завершается.
"""
logging.config.dictConfig(config)
listener = logging.handlers.QueueListener(q, MyHandler())
listener.start()
if os.name == 'posix':
# В POSIX логгер setup уже был настроен в
# родительском процессе, но должен был быть отключён после вызова
# dictConfig.
# В Windows, поскольку fork не используется, логгер setup не будет
# существовать в дочернем процессе, поэтому он будет создан, и сообщение
# появится – отсюда и конструкция "if posix".
logger = logging.getLogger('setup')
logger.critical('Should not appear, because of disabled logger ...')
stop_event.wait()
listener.stop()
def worker_process(config):
"""
Некоторое количество таких процессов порождается для иллюстрации. На
практике это могла бы быть разнородная группа процессов, а не
идентичные друг другу.
Это инициализирует логирование согласно указанной конфигурации
и записывает сотню сообщений со случайными уровнями в случайно выбранные
логгеры.
Добавлена небольшая задержка, чтобы дать другим процессам шанс выполниться. Это
не является строго необходимым, но позволяет немного перемешать вывод от разных
процессов больше, чем если бы её не было.
"""
logging.config.dictConfig(config)
levels = [logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR,
logging.CRITICAL]
loggers = ['foo', 'foo.bar', 'foo.bar.baz',
'spam', 'spam.ham', 'spam.ham.eggs']
if os.name == 'posix':
# В POSIX логгер setup уже был настроен в
# родительском процессе, но должен был быть отключён после вызова
# dictConfig.
# В Windows, поскольку fork не используется, логгер setup не будет
# существовать в дочернем процессе, поэтому он будет создан, и сообщение
# появится – отсюда и конструкция "if posix".
logger = logging.getLogger('setup')
logger.critical('Should not appear, because of disabled logger ...')
for i in range(100):
lvl = random.choice(levels)
logger = logging.getLogger(random.choice(loggers))
logger.log(lvl, 'Message no. %d', i)
time.sleep(0.01)
def main():
q = Queue()
# Главный процесс получает простую конфигурацию, которая выводит информацию в консоль.
config_initial = {
'version': 1,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'level': 'INFO'
}
},
'root': {
'handlers': ['console'],
'level': 'DEBUG'
}
}
# Конфигурация рабочего процесса представляет собой QueueHandler, прикреплённый к
# корневому логгеру, что позволяет отправлять все сообщения в очередь.
# Мы отключаем существующие логгеры, чтобы отключить логгер "setup", используемый в
# родительском процессе. Это необходимо в POSIX, потому что логгер будет
# присутствовать в дочернем процессе после вызова fork().
config_worker = {
'version': 1,
'disable_existing_loggers': True,
'handlers': {
'queue': {
'class': 'logging.handlers.QueueHandler',
'queue': q
}
},
'root': {
'handlers': ['queue'],
'level': 'DEBUG'
}
}
# Конфигурация процесса-слушателя показывает, что вся гибкость
# конфигурации логирования доступна для отправки событий обработчикам так, как
# требуется.
# Мы отключаем существующие логгеры, чтобы отключить логгер "setup", используемый в
# родительском процессе. Это необходимо в POSIX, потому что логгер будет
# присутствовать в дочернем процессе после вызова fork().
config_listener = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'detailed': {
'class': 'logging.Formatter',
'format': '%(asctime)s %(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
},
'simple': {
'class': 'logging.Formatter',
'format': '%(name)-15s %(levelname)-8s %(processName)-10s %(message)s'
}
},
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'formatter': 'simple',
'level': 'INFO'
},
'file': {
'class': 'logging.FileHandler',
'filename': 'mplog.log',
'mode': 'w',
'formatter': 'detailed'
},
'foofile': {
'class': 'logging.FileHandler',
'filename': 'mplog-foo.log',
'mode': 'w',
'formatter': 'detailed'
},
'errors': {
'class': 'logging.FileHandler',
'filename': 'mplog-errors.log',
'mode': 'w',
'formatter': 'detailed',
'level': 'ERROR'
}
},
'loggers': {
'foo': {
'handlers': ['foofile']
}
},
'root': {
'handlers': ['console', 'file', 'errors'],
'level': 'DEBUG'
}
}
# Записываем несколько начальных событий, просто чтобы показать, что логирование в родительском процессе работает
# нормально.
logging.config.dictConfig(config_initial)
logger = logging.getLogger('setup')
logger.info('About to create workers ...')
workers = []
for i in range(5):
wp = Process(target=worker_process, name='worker %d' % (i + 1),
args=(config_worker,))
workers.append(wp)
wp.start()
logger.info('Started worker: %s', wp.name)
logger.info('About to create listener ...')
stop_event = Event()
lp = Process(target=listener_process, name='listener',
args=(q, stop_event, config_listener))
lp.start()
logger.info('Started listener')
# Теперь ожидаем завершения работы рабочих процессов.
for wp in workers:
wp.join()
# Все рабочие процессы завершены, теперь можно остановить прослушивание.
# Логирование в родительском процессе всё ещё работает нормально.
logger.info('Telling listener to stop ...')
stop_event.set()
lp.join()
logger.info('All done.')
if __name__ == '__main__':
main()
Вставка BOM в сообщения, отправляемые в SysLogHandler¶Inserting a BOM into messages sent to a SysLogHandler
RFC 5424 требует, чтобы сообщение Unicode отправлялось демону syslog в виде набора байтов, имеющего следующую структуру: необязательный чисто ASCII-компонент, за которым следует метка порядка байтов UTF-8 (BOM), а затем Unicode, закодированный в UTF-8. (См. соответствующий раздел спецификации.)
В Python 3.1 в SysLogHandler был добавлен код для вставки BOM в сообщение, но, к сожалению, он был реализован некорректно: BOM появлялся в начале сообщения и, следовательно, не допускал наличия чисто ASCII-компонента перед ним.
Поскольку такое поведение ошибочно, некорректный код вставки BOM удаляется из Python 3.2.4 и более поздних версий. Однако он не заменяется, и если требуется создавать сообщения, соответствующие RFC 5424, которые включают BOM, необязательную чисто ASCII-последовательность перед ним и произвольный Unicode после него, закодированный в UTF-8, то необходимо сделать следующее:
Необходимо присоединить экземпляр
Formatterк экземпляруSysLogHandler, указав строку формата, например:'ASCII section\ufeffUnicode section'
Кодовая точка Unicode U+FEFF при кодировании в UTF-8 будет представлена как метка порядка байтов UTF-8 – строка байтов
b'\xef\xbb\xbf'.ASCII-часть следует заменить на любые подходящие заполнители, но необходимо следить, чтобы данные, которые появляются там после подстановки, всегда были в ASCII (таким образом, они останутся без изменений после кодирования UTF-8).
Unicode-часть следует заменить на любые заполнители; если данные после подстановки содержат символы за пределами диапазона ASCII, это нормально – они будут закодированы в UTF-8.
Отформатированное сообщение будет закодировано в UTF-8 с помощью SysLogHandler. Если следовать приведённым выше правилам, можно создавать сообщения, соответствующие RFC 5424. Если этого не делать, модуль logging может не жаловаться, но сообщения не будут соответствовать RFC 5424, и демон syslog может выражать недовольство.
Реализация структурированного ведения журнала¶Implementing structured logging
Хотя большинство сообщений журнала предназначены для чтения человеком и поэтому не предназначены для машинного разбора, могут возникнуть ситуации, когда требуется выводить сообщения в структурированном формате, который может быть разобран программой (без необходимости в сложных регулярных выражениях). Это легко достигается с помощью пакета logging. Существует несколько способов, но ниже приведён простой подход, использующий JSON для сериализации события в машиночитаемом виде.
import json
import logging
class StructuredMessage:
def __init__(self, message, /, **kwargs):
self.message = message
self.kwargs = kwargs
def __str__(self):
return '%s >>> %s' % (self.message, json.dumps(self.kwargs))
_ = StructuredMessage # необязательно, для улучшения читаемости
logging.basicConfig(level=logging.INFO, format='%(message)s')
logging.info(_('message 1', foo='bar', bar='baz', num=123, fnum=123.456))
Если запустить приведённый выше скрипт, он выведет:
message 1 >>> {"fnum": 123.456, "num": 123, "bar": "baz", "foo": "bar"}
Обратите внимание, что порядок элементов может отличаться в зависимости от используемой версии Python.
Если требуется более специализированная обработка, можно использовать пользовательский кодировщик JSON, как в следующем полном примере:
from __future__ import unicode_literals
import json
import logging
# Следующий фрагмент предназначен для того, чтобы скрипт работал без изменений в версиях 2.x и 3.x.
try:
unicode
except NameError:
unicode = str
class Encoder(json.JSONEncoder):
def default(self, o):
if isinstance(o, set):
return tuple(o)
elif isinstance(o, unicode):
return o.encode('unicode_escape').decode('ascii')
return super().default(o)
class StructuredMessage:
def __init__(self, message, /, **kwargs):
self.message = message
self.kwargs = kwargs
def __str__(self):
s = Encoder().encode(self.kwargs)
return '%s >>> %s' % (self.message, s)
_ = StructuredMessage # необязательно, для улучшения читаемости
def main():
logging.basicConfig(level=logging.INFO, format='%(message)s')
logging.info(_('message 1', set_value={1, 2, 3}, snowman='\u2603'))
if __name__ == '__main__':
main()
При запуске приведённого выше скрипта он выведет:
message 1 >>> {"snowman": "\u2603", "set_value": [1, 2, 3]}
Обратите внимание, что порядок элементов может отличаться в зависимости от используемой версии Python.
Настройка обработчиков с помощью dictConfig()¶Customizing handlers with dictConfig()
Иногда требуется настроить обработчики логирования особым образом, и при использовании dictConfig() это можно сделать без создания подклассов. Например, может потребоваться установить владельца файла журнала. В POSIX это легко сделать с помощью shutil.chown(), но файловые обработчики в стандартной библиотеке не предоставляют встроенной поддержки. Можно настроить создание обработчика с помощью обычной функции, такой как:
def owned_file_handler(filename, mode='a', encoding=None, owner=None):
if owner:
if not os.path.exists(filename):
open(filename, 'a').close()
shutil.chown(filename, *owner)
return logging.FileHandler(filename, mode, encoding)
Затем в конфигурации логирования, передаваемой в dictConfig(), можно указать, что обработчик должен быть создан вызовом этой функции:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'default': {
'format': '%(asctime)s %(levelname)s %(name)s %(message)s'
},
},
'handlers': {
'file':{
# Значения ниже извлекаются из этого словаря и
# используются для создания обработчика, установки его уровня и
# его форматтера.
'()': owned_file_handler,
'level':'DEBUG',
'formatter': 'default',
# Значения ниже передаются вызываемому объекту-создателю обработчика
# в качестве именованных аргументов.
'owner': ['pulse', 'pulse'],
'filename': 'chowntest.log',
'mode': 'w',
'encoding': 'utf-8',
},
},
'root': {
'handlers': ['file'],
'level': 'DEBUG',
},
}
В этом примере для иллюстрации права владения устанавливаются с использованием пользователя и группы pulse. Собирая всё вместе в рабочий скрипт, chowntest.py:
import logging, logging.config, os, shutil
def owned_file_handler(filename, mode='a', encoding=None, owner=None):
if owner:
if not os.path.exists(filename):
open(filename, 'a').close()
shutil.chown(filename, *owner)
return logging.FileHandler(filename, mode, encoding)
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'default': {
'format': '%(asctime)s %(levelname)s %(name)s %(message)s'
},
},
'handlers': {
'file':{
# Значения ниже извлекаются из этого словаря и
# используются для создания обработчика, установки его уровня и
# его форматтера.
'()': owned_file_handler,
'level':'DEBUG',
'formatter': 'default',
# Значения ниже передаются вызываемому объекту-создателю обработчика
# в качестве именованных аргументов.
'owner': ['pulse', 'pulse'],
'filename': 'chowntest.log',
'mode': 'w',
'encoding': 'utf-8',
},
},
'root': {
'handlers': ['file'],
'level': 'DEBUG',
},
}
logging.config.dictConfig(LOGGING)
logger = logging.getLogger('mylogger')
logger.debug('A debug message')
Для запуска, вероятно, потребуется выполнить от имени root:
$ sudo python3.3 chowntest.py
$ cat chowntest.log
2013-11-05 09:34:51,128 DEBUG mylogger A debug message
$ ls -l chowntest.log
-rw-r--r-- 1 pulse pulse 55 2013-11-05 09:34 chowntest.log
Обратите внимание, что в этом примере используется Python 3.3, потому что в нём появился shutil.chown(). Этот подход должен работать с любой версией Python, поддерживающей dictConfig() – а именно Python 2.7, 3.2 или новее. В версиях до 3.3 потребовалось бы реализовать фактическую смену владельца, например, с помощью os.chown().
На практике функция создания обработчика может находиться в служебном модуле где-нибудь в вашем проекте. Вместо строки в конфигурации:
'()': owned_file_handler,
можно использовать, например:
'()': 'ext://project.util.owned_file_handler',
где project.util можно заменить на фактическое имя пакета, в котором находится функция. В приведённом рабочем скрипте должно сработать использование 'ext://__main__.owned_file_handler'. Здесь фактический вызываемый объект разрешается с помощью dictConfig() из спецификации ext://.
Этот пример, надеюсь, также показывает, как можно реализовать другие типы изменений файлов – например, установку определённых битов разрешений POSIX – аналогичным образом, с помощью os.chmod().
Разумеется, этот подход можно распространить и на другие типы обработчиков, помимо FileHandler – например, на один из вращающихся файловых обработчиков или на совершенно другой тип обработчика.
Использование определённых стилей форматирования во всём приложении¶Using particular formatting styles throughout your application
В Python 3.2 у Formatter появился именованный параметр style, который, хотя по умолчанию для обратной совместимости он равен %, позволяет указать { или $ для поддержки подходов к форматированию, поддерживаемых str.format() и string.Template. Обратите внимание, что это управляет форматированием сообщений журнала для окончательного вывода в журнал и совершенно не зависит от того, как конструируется отдельное сообщение журнала.
Вызовы логирования (debug(), info() и т.д.) принимают только
позиционные параметры для самого сообщения логирования, а именованные
параметры используются только для определения параметров обработки вызова
(например, именованный параметр exc_info для указания, что информация о трассировке
должна быть записана в журнал, или именованный параметр extra для указания дополнительной
контекстной информации, добавляемой в журнал). Поэтому вы не можете напрямую выполнять
вызовы логирования с использованием синтаксиса str.format() или string.Template,
потому что внутренне пакет logging использует %-форматирование для объединения строки
формата и переменных аргументов. Это нельзя изменить, сохраняя обратную
совместимость, поскольку все существующие вызовы логирования в коде
используют %-форматирование строк.
Высказывались предложения связывать стили форматирования с конкретными регистраторами, но этот подход также сталкивается с проблемами обратной совместимости, поскольку любой существующий код может использовать данное имя регистратора и %-форматирование.
Чтобы логирование работало совместимо между любыми сторонними библиотеками и вашим кодом, решения о форматировании необходимо принимать на уровне отдельного вызова логирования. Это открывает несколько способов, которыми можно реализовать альтернативные стили форматирования.
Использование фабрик LogRecord¶Using LogRecord factories
В Python 3.2, вместе с упомянутыми выше изменениями Formatter, пакет logging получил возможность позволять пользователям устанавливать свои собственные подклассы LogRecord с помощью функции setLogRecordFactory(). Вы можете использовать это, чтобы установить свой собственный подкласс LogRecord, который делает правильные вещи, переопределяя метод getMessage(). В реализации базового класса этого метода происходит форматирование msg % args, и именно здесь можно подставить альтернативное форматирование; однако следует быть осторожным, чтобы поддерживать все стили форматирования и разрешить %-форматирование по умолчанию для обеспечения совместимости с другим кодом. Также следует позаботиться о вызове str(self.msg), как это делает базовая реализация.
Обратитесь к справочной документации по setLogRecordFactory() и LogRecord для получения дополнительной информации.
Использование пользовательских объектов сообщений¶Using custom message objects
Есть еще один, возможно, более простой способ использовать {}- и $-форматирование для построения отдельных сообщений лога. Вы, возможно, помните (из раздела Использование произвольных объектов в качестве сообщений), что при логировании можно использовать произвольный объект в качестве строки формата сообщения, и пакет logging вызовет str() для этого объекта, чтобы получить фактическую строку формата. Рассмотрим следующие два класса:
class BraceMessage:
def __init__(self, fmt, /, *args, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs
def __str__(self):
return self.fmt.format(*self.args, **self.kwargs)
class DollarMessage:
def __init__(self, fmt, /, **kwargs):
self.fmt = fmt
self.kwargs = kwargs
def __str__(self):
from string import Template
return Template(self.fmt).substitute(**self.kwargs)
Любой из них можно использовать вместо строки формата, чтобы разрешить {}- или $-форматирование для построения фактической части «message», которая появляется в форматированном выводе лога вместо «%(message)s», «{message}» или «$message». Если вам кажется неудобным использовать имена классов каждый раз при логировании, вы можете сделать это более приятным, используя псевдоним, такой как M или _ для сообщения (или, возможно, __, если вы используете _ для локализации).
Примеры этого подхода приведены ниже. Во-первых, форматирование с помощью str.format():
>>> __ = BraceMessage
>>> print(__('Message with {0} {1}', 2, 'placeholders'))
Message with 2 placeholders
>>> class Point: pass
...
>>> p = Point()
>>> p.x = 0.5
>>> p.y = 0.5
>>> print(__('Message with coordinates: ({point.x:.2f}, {point.y:.2f})', point=p))
Message with coordinates: (0.50, 0.50)
Во-вторых, форматирование с помощью string.Template:
>>> __ = DollarMessage
>>> print(__('Message with $num $what', num=2, what='placeholders'))
Message with 2 placeholders
>>>
Стоит отметить, что при таком подходе вы не платите значительных потерь производительности: фактическое форматирование происходит не при вызове логирования, а когда (и если) сообщение лога действительно должно быть выведено в лог обработчиком. Так что единственная необычная вещь, которая может вас сбить с толку, это то, что круглые скобки ставятся вокруг строки формата и аргументов, а не только вокруг строки формата. Это потому, что нотация __ – это просто синтаксический сахар для вызова конструктора одного из классов XXXMessage, показанных выше.
Настройка фильтров с помощью dictConfig()¶Configuring filters with dictConfig()
Можно настраивать фильтры с помощью dictConfig(), хотя с первого взгляда может быть неочевидно, как это сделать (поэтому и дан этот рецепт). Поскольку Filter – единственный класс фильтра, включенный в стандартную библиотеку, и вряд ли он удовлетворит многие требования (он присутствует только как базовый класс), вам, как правило, потребуется определить свой собственный подкласс Filter с переопределенным методом filter(). Для этого укажите ключ () в словаре конфигурации для фильтра, указав вызываемый объект, который будет использоваться для создания фильтра (класс – наиболее очевидный вариант, но вы можете предоставить любой вызываемый объект, возвращающий экземпляр Filter). Вот полный пример:
import logging
import logging.config
import sys
class MyFilter(logging.Filter):
def __init__(self, param=None):
self.param = param
def filter(self, record):
if self.param is None:
allow = True
else:
allow = self.param not in record.msg
if allow:
record.msg = 'changed: ' + record.msg
return allow
LOGGING = {
'version': 1,
'filters': {
'myfilter': {
'()': MyFilter,
'param': 'noshow',
}
},
'handlers': {
'console': {
'class': 'logging.StreamHandler',
'filters': ['myfilter']
}
},
'root': {
'level': 'DEBUG',
'handlers': ['console']
},
}
if __name__ == '__main__':
logging.config.dictConfig(LOGGING)
logging.debug('hello')
logging.debug('hello - noshow')
Этот пример показывает, как можно передавать конфигурационные данные вызываемому объекту, который создает экземпляр, в виде именованных параметров. При запуске приведенный выше скрипт выведет:
changed: hello
что показывает, что фильтр работает в соответствии с настройками.
Несколько дополнительных моментов, на которые стоит обратить внимание:
Если вы не можете сослаться на вызываемый объект напрямую в конфигурации (например, если он находится в другом модуле, и вы не можете импортировать его напрямую в том месте, где находится словарь конфигурации), вы можете использовать форму
ext://..., как описано в разделе Доступ к внешним объектам. Например, в приведенном выше примере можно было использовать текст'ext://__main__.MyFilter'вместоMyFilter.Помимо фильтров, этот метод также можно использовать для настройки пользовательских обработчиков и форматтеров. Смотрите раздел Пользовательские объекты для получения дополнительной информации о том, как logging поддерживает использование пользовательских объектов в своей конфигурации, а также см. другой рецепт из этой книги рецептов Настройка обработчиков с помощью dictConfig() выше.
Настраиваемое форматирование исключений¶Customized exception formatting
Могут возникнуть ситуации, когда вы захотите настроить форматирование исключений – для примера, предположим, вы хотите ровно одну строку на каждое событие лога, даже если присутствует информация об исключении. Вы можете сделать это с помощью пользовательского класса форматтера, как показано в следующем примере:
import logging
class OneLineExceptionFormatter(logging.Formatter):
def formatException(self, exc_info):
"""
Форматировать исключение так, чтобы оно выводилось одной строкой.
"""
result = super().formatException(exc_info)
return repr(result) # или форматировать одной строкой по своему усмотрению
def format(self, record):
s = super().format(record)
if record.exc_text:
s = s.replace('\n', '') + '|'
return s
def configure_logging():
fh = logging.FileHandler('output.txt', 'w')
f = OneLineExceptionFormatter('%(asctime)s|%(levelname)s|%(message)s|',
'%d/%m/%Y %H:%M:%S')
fh.setFormatter(f)
root = logging.getLogger()
root.setLevel(logging.DEBUG)
root.addHandler(fh)
def main():
configure_logging()
logging.info('Sample message')
try:
x = 1 / 0
except ZeroDivisionError as e:
logging.exception('ZeroDivisionError: %s', e)
if __name__ == '__main__':
main()
При запуске это создает файл ровно с двумя строками:
28/01/2015 07:21:23|INFO|Sample message|
28/01/2015 07:21:23|ERROR|ZeroDivisionError: integer division or modulo by zero|'Traceback (most recent call last):\n File "logtest7.py", line 30, in main\n x = 1 / 0\nZeroDivisionError: integer division or modulo by zero'|
Хотя описанный выше подход упрощен, он показывает путь к тому, как можно форматировать информацию об исключениях по своему вкусу. Модуль traceback может быть полезен для более специализированных нужд.
Озвучивание сообщений лога¶Speaking logging messages
Могут быть ситуации, когда желательно выводить сообщения лога в звуковом, а не визуальном формате. Это легко сделать, если в вашей системе доступна функция преобразования текста в речь (TTS), даже если у нее нет привязки к Python. Большинство TTS-систем имеют программу командной строки, которую можно запустить, и ее можно вызвать из обработчика с помощью subprocess. Здесь предполагается, что программы командной строки TTS не будут ожидать взаимодействия с пользователем или занимать много времени для завершения, и что частота сообщений лога не будет настолько высокой, чтобы перегружать пользователя сообщениями, и что допустимо проговаривать сообщения по одному, а не одновременно. В приведенном ниже примере реализации ожидается, пока одно сообщение не будет произнесено, прежде чем обрабатывать следующее, и это может заставить другие обработчики ждать. Вот короткий пример, демонстрирующий подход, который предполагает, что доступен TTS-пакет espeak:
import logging
import subprocess
import sys
class TTSHandler(logging.Handler):
def emit(self, record):
msg = self.format(record)
# Говорить медленно женским английским голосом.
cmd = ['espeak', '-s150', '-ven+f3', msg]
p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
# дождаться завершения программы
p.communicate()
def configure_logging():
h = TTSHandler()
root = logging.getLogger()
root.addHandler(h)
# стандартный форматтер просто возвращает сообщение
root.setLevel(logging.DEBUG)
def main():
logging.info('Hello')
logging.debug('Goodbye')
if __name__ == '__main__':
configure_logging()
sys.exit(main())
При запуске этот скрипт должен сказать «Hello», а затем «Goodbye» женским голосом.
Описанный выше подход, конечно, можно адаптировать для других TTS-систем и даже для других систем, которые могут обрабатывать сообщения через внешние программы, запускаемые из командной строки.
Буферизация сообщений лога и условный вывод¶Buffering logging messages and outputting them conditionally
Могут возникнуть ситуации, когда вы хотите записывать сообщения во временную область и выводить их только при наступлении определенного условия. Например, вы можете начать запись отладочных событий в функции, и если функция завершится без ошибок, вы не захотите засорять лог собранной отладочной информацией, но если возникнет ошибка, вы захотите вывести всю отладочную информацию вместе с ошибкой.
Вот пример, показывающий, как это можно сделать с помощью декоратора для ваших функций, где вы хотите, чтобы логирование вело себя таким образом. Он использует logging.handlers.MemoryHandler, который позволяет буферизовать зарегистрированные события до наступления некоторого условия, после чего буферизованные события flushed – передаются другому обработчику (обработчику target) для обработки. По умолчанию MemoryHandler сбрасывается, когда его буфер заполняется или встречается событие, уровень которого больше или равен указанному порогу. Вы можете использовать этот рецепт с более специализированным подклассом MemoryHandler, если хотите настроить поведение сброса.
Пример скрипта содержит простую функцию foo, которая просто перебирает все уровни логирования, записывая в sys.stderr информацию о том, какой уровень будет использоваться, а затем регистрирует сообщение на этом уровне. Вы можете передать параметр в foo, который, если равен true, будет регистрировать на уровнях ERROR и CRITICAL – в противном случае он регистрирует только на уровнях DEBUG, INFO и WARNING.
Скрипт просто настраивает декорирование foo декоратором, который будет выполнять необходимое условное логирование. Декоратор принимает регистратор в качестве параметра и подключает обработчик памяти на время вызова декорированной функции. Декоратор можно дополнительно параметризовать с помощью целевого обработчика, уровня, при котором должен происходить сброс, и емкости буфера (количество буферизируемых записей). По умолчанию они равны StreamHandler, который пишет в sys.stderr, logging.ERROR и 100 соответственно.
Вот скрипт:
import logging
from logging.handlers import MemoryHandler
import sys
logger = logging.getLogger(__name__)
logger.addHandler(logging.NullHandler())
def log_if_errors(logger, target_handler=None, flush_level=None, capacity=None):
if target_handler is None:
target_handler = logging.StreamHandler()
if flush_level is None:
flush_level = logging.ERROR
if capacity is None:
capacity = 100
handler = MemoryHandler(capacity, flushLevel=flush_level, target=target_handler)
def decorator(fn):
def wrapper(*args, **kwargs):
logger.addHandler(handler)
try:
return fn(*args, **kwargs)
except Exception:
logger.exception('call failed')
raise
finally:
super(MemoryHandler, handler).flush()
logger.removeHandler(handler)
return wrapper
return decorator
def write_line(s):
sys.stderr.write('%s\n' % s)
def foo(fail=False):
write_line('about to log at DEBUG ...')
logger.debug('Actually logged at DEBUG')
write_line('about to log at INFO ...')
logger.info('Actually logged at INFO')
write_line('about to log at WARNING ...')
logger.warning('Actually logged at WARNING')
if fail:
write_line('about to log at ERROR ...')
logger.error('Actually logged at ERROR')
write_line('about to log at CRITICAL ...')
logger.critical('Actually logged at CRITICAL')
return fail
decorated_foo = log_if_errors(logger)(foo)
if __name__ == '__main__':
logger.setLevel(logging.DEBUG)
write_line('Calling undecorated foo with False')
assert not foo(False)
write_line('Calling undecorated foo with True')
assert foo(True)
write_line('Calling decorated foo with False')
assert not decorated_foo(False)
write_line('Calling decorated foo with True')
assert decorated_foo(True)
При запуске этого скрипта отобразится следующий вывод:
Calling undecorated foo with False
about to log at DEBUG ...
about to log at INFO ...
about to log at WARNING ...
Calling undecorated foo with True
about to log at DEBUG ...
about to log at INFO ...
about to log at WARNING ...
about to log at ERROR ...
about to log at CRITICAL ...
Calling decorated foo with False
about to log at DEBUG ...
about to log at INFO ...
about to log at WARNING ...
Calling decorated foo with True
about to log at DEBUG ...
about to log at INFO ...
about to log at WARNING ...
about to log at ERROR ...
Actually logged at DEBUG
Actually logged at INFO
Actually logged at WARNING
Actually logged at ERROR
about to log at CRITICAL ...
Actually logged at CRITICAL
Как видно, фактический вывод журнала происходит только при регистрации события, уровень которого ERROR или выше, но в этом случае также регистрируются все предыдущие события с более низкими уровнями.
Конечно, можно использовать обычные средства декорирования:
@log_if_errors(logger)
def foo(fail=False):
...
Форматирование времени с использованием UTC (GMT) через конфигурацию¶Formatting times using UTC (GMT) via configuration
Иногда требуется форматировать время по UTC, что можно сделать с помощью класса такого как UTCFormatter, показанного ниже:
import logging
import time
class UTCFormatter(logging.Formatter):
converter = time.gmtime
и затем можно использовать UTCFormatter в своём коде вместо
Formatter. Если требуется сделать это через конфигурацию, можно
воспользоваться API dictConfig(), как показано в следующем
полном примере:
import logging
import logging.config
import time
class UTCFormatter(logging.Formatter):
converter = time.gmtime
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'formatters': {
'utc': {
'()': UTCFormatter,
'format': '%(asctime)s %(message)s',
},
'local': {
'format': '%(asctime)s %(message)s',
}
},
'handlers': {
'console1': {
'class': 'logging.StreamHandler',
'formatter': 'utc',
},
'console2': {
'class': 'logging.StreamHandler',
'formatter': 'local',
},
},
'root': {
'handlers': ['console1', 'console2'],
}
}
if __name__ == '__main__':
logging.config.dictConfig(LOGGING)
logging.warning('The local time is %s', time.asctime())
При запуске этого скрипта он должен вывести примерно следующее:
2015-10-17 12:53:29,501 The local time is Sat Oct 17 13:53:29 2015
2015-10-17 13:53:29,501 The local time is Sat Oct 17 13:53:29 2015
показывая, как время форматируется как в местном времени, так и в UTC, по одному для каждого обработчика.
Использование контекстного менеджера для выборочного журналирования¶Using a context manager for selective logging
Бывают ситуации, когда полезно временно изменить конфигурацию журналирования, а затем вернуть её обратно после выполнения каких-то действий. Для этого контекстный менеджер – самый очевидный способ сохранить и восстановить контекст журналирования. Вот простой пример такого контекстного менеджера, который позволяет по желанию изменить уровень журналирования и добавить обработчик журнала исключительно в области действия контекстного менеджера:
import logging
import sys
class LoggingContext:
def __init__(self, logger, level=None, handler=None, close=True):
self.logger = logger
self.level = level
self.handler = handler
self.close = close
def __enter__(self):
if self.level is not None:
self.old_level = self.logger.level
self.logger.setLevel(self.level)
if self.handler:
self.logger.addHandler(self.handler)
def __exit__(self, et, ev, tb):
if self.level is not None:
self.logger.setLevel(self.old_level)
if self.handler:
self.logger.removeHandler(self.handler)
if self.handler and self.close:
self.handler.close()
# неявный возврат None => не подавлять исключения
Если указать значение уровня, уровень регистратора устанавливается на это значение в области действия блока with, охватываемого контекстным менеджером. Если указать обработчик, он добавляется к регистратору при входе в блок и удаляется при выходе из блока. Также можно попросить менеджер закрыть обработчик при выходе из блока – это можно сделать, если обработчик больше не нужен.
Чтобы проиллюстрировать, как это работает, можно добавить следующий блок кода к предыдущему:
if __name__ == '__main__':
logger = logging.getLogger('foo')
logger.addHandler(logging.StreamHandler())
logger.setLevel(logging.INFO)
logger.info('1. This should appear just once on stderr.')
logger.debug('2. This should not appear.')
with LoggingContext(logger, level=logging.DEBUG):
logger.debug('3. This should appear once on stderr.')
logger.debug('4. This should not appear.')
h = logging.StreamHandler(sys.stdout)
with LoggingContext(logger, level=logging.DEBUG, handler=h, close=True):
logger.debug('5. This should appear twice - once on stderr and once on stdout.')
logger.info('6. This should appear just once on stderr.')
logger.debug('7. This should not appear.')
Изначально устанавливаем уровень регистратора равным INFO, поэтому сообщение №1 отображается, а
сообщение №2 – нет. Затем временно меняем уровень на DEBUG в
следующем блоке with, и сообщение №3 отображается. После выхода из блока
уровень регистратора восстанавливается до INFO, поэтому сообщение №4 не отображается. В
следующем блоке with снова устанавливаем уровень DEBUG, но также добавляем обработчик,
записывающий в sys.stdout. Таким образом, сообщение №5 отображается дважды на консоли (один раз
через stderr и один раз через stdout). После завершения оператора with
состояние возвращается к исходному, поэтому сообщение №6 отображается (как сообщение
№1), а сообщение №7 – нет (как сообщение №2).
Если запустить полученный скрипт, результат будет следующим:
$ python logctx.py
1. This should appear just once on stderr.
3. This should appear once on stderr.
5. This should appear twice - once on stderr and once on stdout.
5. This should appear twice - once on stderr and once on stdout.
6. This should appear just once on stderr.
Если запустить его снова, но перенаправить stderr в /dev/null, мы увидим следующее,
что является единственным сообщением, записанным в stdout:
$ python logctx.py 2>/dev/null
5. This should appear twice - once on stderr and once on stdout.
Ещё раз, но перенаправляя stdout в /dev/null, получаем:
$ python logctx.py >/dev/null
1. This should appear just once on stderr.
3. This should appear once on stderr.
5. This should appear twice - once on stderr and once on stdout.
6. This should appear just once on stderr.
В этом случае сообщение №5, выведенное в stdout, не отображается, как и ожидалось.
Разумеется, описанный подход можно обобщить, например, для временного подключения фильтров журналирования. Обратите внимание, что приведённый выше код работает как в Python 2, так и в Python 3.
Шаблон для запуска CLI-приложения¶A CLI application starter template
Вот пример, показывающий, как можно:
Использовать уровень журналирования на основе аргументов командной строки
Перенаправлять вызовы к нескольким подкомандам в отдельных файлах, все с журналированием на одном уровне согласованным образом
Использовать простую минимальную конфигурацию
Предположим, у нас есть приложение командной строки, которое останавливает, запускает или
перезапускает некоторые службы. Для иллюстрации это может быть организовано
в виде файла app.py, который является главным скриптом приложения, с отдельными
командами, реализованными в start.py, stop.py и restart.py. Предположим
также, что мы хотим управлять степенью подробности вывода приложения через
аргумент командной строки с значением по умолчанию logging.INFO. Вот один из способов,
как мог бы быть написан app.py:
import argparse
import importlib
import logging
import os
import sys
def main(args=None):
scriptname = os.path.basename(__file__)
parser = argparse.ArgumentParser(scriptname)
levels = ('DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL')
parser.add_argument('--log-level', default='INFO', choices=levels)
subparsers = parser.add_subparsers(dest='command',
help='Available commands:')
start_cmd = subparsers.add_parser('start', help='Start a service')
start_cmd.add_argument('name', metavar='NAME',
help='Name of service to start')
stop_cmd = subparsers.add_parser('stop',
help='Stop one or more services')
stop_cmd.add_argument('names', metavar='NAME', nargs='+',
help='Name of service to stop')
restart_cmd = subparsers.add_parser('restart',
help='Restart one or more services')
restart_cmd.add_argument('names', metavar='NAME', nargs='+',
help='Name of service to restart')
options = parser.parse_args()
# весь код для отправки команд мог бы быть в этом файле. Для целей
# только в целях иллюстрации каждая команда реализована в отдельном модуле.
try:
mod = importlib.import_module(options.command)
cmd = getattr(mod, 'command')
except (ImportError, AttributeError):
print('Unable to find the code for command \'%s\'' % options.command)
return 1
# Здесь можно было бы сделать по-хитрому и загрузить конфигурацию из файла или словаря
logging.basicConfig(level=options.log_level,
format='%(levelname)s %(name)s %(message)s')
cmd(options)
if __name__ == '__main__':
sys.exit(main())
А команды start, stop и restart могут быть реализованы в
отдельных модулях, например, для запуска:
# start.py
import logging
logger = logging.getLogger(__name__)
def command(options):
logger.debug('About to start %s', options.name)
# здесь происходит фактическая обработка команды...
logger.info('Started the \'%s\' service.', options.name)
и аналогично для остановки:
# stop.py
import logging
logger = logging.getLogger(__name__)
def command(options):
n = len(options.names)
if n == 1:
plural = ''
services = '\'%s\'' % options.names[0]
else:
plural = 's'
services = ', '.join('\'%s\'' % name for name in options.names)
i = services.rfind(', ')
services = services[:i] + ' and ' + services[i + 2:]
logger.debug('About to stop %s', services)
# здесь происходит фактическая обработка команды...
logger.info('Stopped the %s service%s.', services, plural)
и аналогично для перезапуска:
# restart.py
import logging
logger = logging.getLogger(__name__)
def command(options):
n = len(options.names)
if n == 1:
plural = ''
services = '\'%s\'' % options.names[0]
else:
plural = 's'
services = ', '.join('\'%s\'' % name for name in options.names)
i = services.rfind(', ')
services = services[:i] + ' and ' + services[i + 2:]
logger.debug('About to restart %s', services)
# здесь происходит фактическая обработка команды...
logger.info('Restarted the %s service%s.', services, plural)
Если запустить это приложение с уровнем журналирования по умолчанию, мы получим примерно такой вывод:
$ python app.py start foo
INFO start Started the 'foo' service.
$ python app.py stop foo bar
INFO stop Stopped the 'foo' and 'bar' services.
$ python app.py restart foo bar baz
INFO restart Restarted the 'foo', 'bar' and 'baz' services.
Первое слово – уровень журналирования, а второе – имя модуля или пакета, в котором было зарегистрировано событие.
Если изменить уровень журналирования, можно изменить объём информации, отправляемой в журнал. Например, чтобы получить больше информации:
$ python app.py --log-level DEBUG start foo
DEBUG start About to start foo
INFO start Started the 'foo' service.
$ python app.py --log-level DEBUG stop foo bar
DEBUG stop About to stop 'foo' and 'bar'
INFO stop Stopped the 'foo' and 'bar' services.
$ python app.py --log-level DEBUG restart foo bar baz
DEBUG restart About to restart 'foo', 'bar' and 'baz'
INFO restart Restarted the 'foo', 'bar' and 'baz' services.
А если нужно меньше:
$ python app.py --log-level WARNING start foo
$ python app.py --log-level WARNING stop foo bar
$ python app.py --log-level WARNING restart foo bar baz
В этом случае команды ничего не выводят в консоль, поскольку ни одно сообщение
уровня WARNING и выше ими не записывается.
Графический интерфейс Qt для журналирования¶A Qt GUI for logging
Время от времени возникает вопрос о том, как организовать логирование в GUI-приложении. Фреймворк Qt – популярная кроссплатформенная UI-среда с привязками к Python через библиотеки PySide2 или PyQt5.
В следующем примере показано, как выполнять журналирование в графический интерфейс Qt. Он представляет простой
класс QtHandler, который принимает вызываемый объект – слот главного потока, обновляющий GUI.
Также создаётся рабочий поток, чтобы продемонстрировать возможность журналирования как из самого интерфейса
(через кнопку для ручной записи), так и из фонового рабочего потока (который в данном случае просто
выводит сообщения со случайными уровнями и случайными короткими задержками).
Рабочий поток реализован с помощью класса QThread из Qt, а не модуля
threading, поскольку бывают ситуации, когда необходимо использовать
QThread, который обеспечивает лучшую интеграцию с другими компонентами Qt.
Код должен работать с последними версиями PySide2 или PyQt5.
Вы сможете адаптировать подход для более старых версий Qt. Обратитесь
к комментариям в фрагменте кода за более подробной информацией.
import datetime
import logging
import random
import sys
import time
# Обработка мелких различий между PySide2 и PyQt5
try:
from PySide2 import QtCore, QtGui, QtWidgets
Signal = QtCore.Signal
Slot = QtCore.Slot
except ImportError:
from PyQt5 import QtCore, QtGui, QtWidgets
Signal = QtCore.pyqtSignal
Slot = QtCore.pyqtSlot
logger = logging.getLogger(__name__)
#
# Сигналы должны содержаться в QObject или подклассе, чтобы корректно
# инициализироваться.
#
class Signaller(QtCore.QObject):
signal = Signal(str, logging.LogRecord)
#
# Вывод в графический интерфейс Qt должен происходить только в главном потоке. Поэтому данный
# обработчик спроектирован так, чтобы принимать функцию-слот, настроенную на выполнение в главном
# потоке. В этом примере функция принимает строковый аргумент, который является
# отформатированным сообщением лога, и запись лога, которая его породила. Отформатированная
# строка – это просто удобство; можно отформатировать строку для вывода любым способом
# в самой функции-слоте.
#
# Функцию-слот можно настроить на любые нужные обновления GUI. Обработчик
# не знает и не заботится о конкретных элементах интерфейса.
#
class QtHandler(logging.Handler):
def __init__(self, slotfunc, *args, **kwargs):
super().__init__(*args, **kwargs)
self.signaller = Signaller()
self.signaller.signal.connect(slotfunc)
def emit(self, record):
s = self.format(record)
self.signaller.signal.emit(s, record)
#
# В этом примере используются QThreads, что означает, что потоки на уровне Python
# называются как-то вроде "Dummy-1". Функция ниже получает имя Qt
# текущего потока.
#
def ctname():
return QtCore.QThread.currentThread().objectName()
#
# Используется для генерации случайных уровней для логирования.
#
LEVELS = (logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR,
logging.CRITICAL)
#
# Этот класс-воркер представляет работу, выполняемую в потоке, отдельном от
# главного потока. Поток запускается на выполнение работы по нажатию кнопки,
# которая соединяется со слотом в воркере.
#
# Поскольку значение threadName по умолчанию в LogRecord не очень полезно, мы добавляем
# qThreadName, содержащий имя QThread, вычисленное выше, и передаём это
# значение в словаре "extra", который используется для обновления LogRecord с помощью
# имя QThread.
#
# Этот пример рабочего просто выводит сообщения последовательно, перемежая их случайными задержками порядка нескольких секунд.
# Позволяет потоку выполняться до прерывания. Это обеспечивает достаточно чистую остановку потока.
#
class Worker(QtCore.QObject):
@Slot()
def start(self):
extra = {'qThreadName': ctname() }
logger.debug('Started work', extra=extra)
i = 1
# Реализует простой пользовательский интерфейс для этого примера из кулинарной книги. Он содержит:
# * Окно текстового редактора только для чтения, которое содержит форматированные сообщения журнала
while not QtCore.QThread.currentThread().isInterruptionRequested():
delay = 0.5 + random.random() * 2
time.sleep(delay)
level = random.choice(LEVELS)
logger.log(level, 'Message after delay of %3.1f: %d', delay, i, extra=extra)
i += 1
#
# * Кнопка запуска работы и записи в журнал в отдельном потоке
#
# * Кнопка записи чего-либо из основного потока
# * Кнопка очистки окна журнала
# Устанавливает моноширинный шрифт, принятый по умолчанию на платформе
# для Qt6
#
class Window(QtWidgets.QWidget):
COLORS = {
logging.DEBUG: 'black',
logging.INFO: 'blue',
logging.WARNING: 'orange',
logging.ERROR: 'red',
logging.CRITICAL: 'purple',
}
def __init__(self, app):
super().__init__()
self.app = app
self.textedit = te = QtWidgets.QPlainTextEdit(self)
# Устанавливает моноширинный шрифт по умолчанию для платформы
f = QtGui.QFont('nosuchfont')
f.setStyleHint(f.Monospace)
te.setFont(f)
te.setReadOnly(True)
PB = QtWidgets.QPushButton
self.work_button = PB('Start background work', self)
self.log_button = PB('Log a message at a random level', self)
self.clear_button = PB('Clear log window', self)
self.handler = h = QtHandler(self.update_status)
# Размещает все виджеты
fs = '%(asctime)s %(qThreadName)-12s %(levelname)-8s %(message)s'
formatter = logging.Formatter(fs)
h.setFormatter(formatter)
logger.addHandler(h)
# Подключает слоты и сигналы, не относящиеся к рабочему
app.aboutToQuit.connect(self.force_quit)
# Запускает новый рабочий поток и подключает слоты для рабочего
layout = QtWidgets.QVBoxLayout(self)
layout.addWidget(te)
layout.addWidget(self.work_button)
layout.addWidget(self.log_button)
layout.addWidget(self.clear_button)
self.setFixedSize(900, 400)
# После запуска кнопка должна быть отключена
self.log_button.clicked.connect(self.manual_update)
self.clear_button.clicked.connect(self.clear_display)
# Запустить новый рабочий поток и подключить слоты для рабочего
self.start_thread()
self.work_button.clicked.connect(self.worker.start)
# Это запустит цикл событий в рабочем потоке
self.work_button.clicked.connect(lambda : self.work_button.setEnabled(False))
def start_thread(self):
self.worker = Worker()
self.worker_thread = QtCore.QThread()
self.worker.setObjectName('Worker')
self.worker_thread.setObjectName('WorkerThread') # Просто скажите рабочему остановиться, затем скажите ему выйти и дождитесь этого
self.worker.moveToThread(self.worker_thread)
# Для использования при закрытии окна
self.worker_thread.start()
def kill_thread(self):
# Функции ниже обновляют интерфейс и выполняются в основном потоке, поскольку слоты настроены именно там
# Эта функция использует переданное форматированное сообщение, но также использует информацию из записи, чтобы отформатировать сообщение подходящим цветом в соответствии с его серьёзностью (уровнем).
self.worker_thread.requestInterruption()
if self.worker_thread.isRunning():
self.worker_thread.quit()
self.worker_thread.wait()
else:
print('worker has already exited.')
def force_quit(self):
# Для использования при закрытии окна
if self.worker_thread.isRunning():
self.kill_thread()
# Функции ниже обновляют пользовательский интерфейс и выполняются в главном потоке, потому что
# здесь настраиваются слоты
@Slot(str, logging.LogRecord)
def update_status(self, status, record):
color = self.COLORS.get(record.levelno, 'black')
s = '<pre><font color="%s">%s</font></pre>' % (color, status)
self.textedit.appendHtml(s)
@Slot()
def manual_update(self):
# Эта функция использует переданное форматированное сообщение, а также использует
# информацию из записи для форматирования сообщения в подходящий
# цвет в соответствии с его серьёзностью (уровнем).
level = random.choice(LEVELS)
extra = {'qThreadName': ctname() }
logger.log(level, 'Manually logged!', extra=extra)
@Slot()
def clear_display(self):
self.textedit.clear()
def main():
QtCore.QThread.currentThread().setObjectName('MainThread')
logging.getLogger().setLevel(logging.DEBUG)
app = QtWidgets.QApplication(sys.argv)
example = Window(app)
example.show()
sys.exit(app.exec_())
if __name__=='__main__':
main()