2010-10-23 2 views
3

Я думаю, что может быть полезно посыпать некоторые отладочные записи в моем приложении (программу типа рисования) и записать эту информацию в файл. Моя текущая стратегия отладки заключается в том, чтобы подключить пользовательский прослушиватель исключений (sys.excepthook) и разрешить пользователю отправлять мне по электронной почте копию трассировки стека, которая вызвала сбой.Стратегия ведения журнала для программы GUI

Это было очень удобно при просмотре того, что пользователь сделал, чтобы вызвать сбой программы, но я чувствую, что файл журнала наверняка поможет. Мне интересно, что лучший способ сделать это. Я подумываю включить ведение журнала через коммутатор командной строки и создать журнал для «запуска» программы и отправить по электронной почте копию журнала при сбое. Тем не менее, журнал не поможет, если приложение не находится в режиме отладки!

Я немного беспокоюсь о том, что журнал заполняется слишком быстро - если я помещаю вход в некоторые обработчики событий движения мыши, тогда он создаст много записей. Кроме того, файл журнала может расти довольно крупным и просто заполняться ненужной информацией для меня при анализе отчета об ошибке.

Как вы, ребята, имеете дело с этим? Меня интересует частота регистрации - поскольку мое приложение реагирует на многие события (например, движение мыши, в зависимости от пользовательского ввода), я не хочу создавать избыточные записи.

+0

Вы прочитали это: http://docs.python.org/library/logging.html? –

+0

Да, но мне было интересно, сколько информации на самом деле записывается особенно в обработчиках событий мыши, поскольку они могут часто вызываться. –

+0

Пожалуйста, уточните ** вопрос, поэтому он содержит ** все ** детали. –

ответ

5

Как уже говорилось, вы можете использовать модуль регистратора. Вы можете установить уровень ведения журнала по умолчанию (например, предупреждение) и поместить в код все виды сообщений, поскольку отладка до критического значения. Как скромное объяснение, если вы установили уровень ведения журнала как предупреждение, даже если ваши сообщения об ошибках в журнале кода они не будут отображаться в файле (или stdout). Это связано с тем, что модуль протоколирования будет регистрировать только сообщения с приоритетом выше или равным предупреждению (предупреждение, ошибка и критическое).

В качестве простого объяснения взглянуть на этот код:

import logging 
import logging.handlers as handlers 

logger = logging.getLogger('myapp') 
hdlr = logging.FileHandler('/tmp/myapp.log') 
formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') 
hdlr.setFormatter(formatter) 
logger.addHandler(hdlr) 
logger.setLevel(logging.WARNING) 

logger.debug('debug!') 
logger.info('info!') 
logger.warning('warning!') 
logger.error('error!') 
logger.critical('critical!') 

Это создает файл с именем myapp.log:

[email protected]~: cat /tmp/myapp.log 
2010-11-05 12:27:25,359 WARNING: warning! 
2010-11-05 12:27:25,362 ERROR: error! 
2010-11-05 12:27:26,071 CRITICAL: critical! 
[email protected]~: 

Если вы беспокоитесь о размере файла, который вы можете использовать вращающийся log, witch будет отбрасывать самые старые журналы, основанные на ваших критериях:

import logging 
import logging.handlers as handlers 

logger = logging.getLogger('myapp') 
hdlr = handlers.RotatingFileHandler('/tmp/log/myapp.log', maxBytes=100, backupCount=5) 
formatter = logging.Formatter('%(asctime)s %(levelname)s: %(message)s') 
hdlr.setFormatter(formatter) 
logger.addHandler(hdlr) 
logger.setLevel(logging.WARNING) 

for i in range(20): 
    logger.debug('debug%i!'%i) 
    logger.info('info%i!'%i) 
    logger.warning('warning%i!'%i) 
    logger.error('error%i!'%i) 
    logger.critical('critical%i!'%i) 

В этом случае я использовал лог-файл e с максимальным размером 100 байт (довольно небольшим, вы должны поднять его) и количеством резервных копий 5. Это означает, что когда журнал достигает 100 байт, он будет «повернут»: будет создан новый (и пустой) myapp.log и старый станет myapp.log.1. При следующем ротации myapp.log.1 станет myapp.log.2, в myapp.log появится новый файл myapp.log.1. Он будет повторяться до тех пор, пока у меня не будет myapp.log, myapp.log.1, myapp.log.2, ... myapp.log.n (в этом примере предел будет myapp.log.5). Когда мы нажмем на это, и журнал должен быть повернут, файл myapp.log.5 будет отброшен. Итак, ограничение размера, если 5 * 100 байт.

Посмотрите, что случилось:

[email protected]~: ls /tmp/log/ 
myapp.log myapp.log.1 myapp.log.2 myapp.log.3 myapp.log.4 myapp.log.5 
[email protected]~: cat /tmp/log/myapp.log 
2010-11-05 12:33:52,369 ERROR: error19! 
2010-11-05 12:33:52,376 CRITICAL: critical19! 
[email protected]~: cat /tmp/log/myapp.log.1 
2010-11-05 12:33:52,362 CRITICAL: critical18! 
2010-11-05 12:33:52,369 WARNING: warning19! 
[email protected]~: cat /tmp/log/myapp.log.2 
2010-11-05 12:33:52,355 WARNING: warning18! 
2010-11-05 12:33:52,362 ERROR: error18! 
[email protected]~: cat /tmp/log/myapp.log.3 
2010-11-05 12:33:52,348 ERROR: error17! 
2010-11-05 12:33:52,355 CRITICAL: critical17! 
[email protected]~: cat /tmp/log/myapp.log.4 
2010-11-05 12:33:52,340 CRITICAL: critical16! 
2010-11-05 12:33:52,348 WARNING: warning17! 
[email protected]~: cat /tmp/log/myapp.log.5 
2010-11-05 12:33:52,333 WARNING: warning16! 
2010-11-05 12:33:52,340 ERROR: error16! 
[email protected]~: 

Как вы можете видеть, что мы потеряли много журналов (0-15), но самые последние есть, сохранение свободного пространства пользователя. Не забудьте прочитать журнал снизу вверх :)