Стратегия ведения журнала для программы с графическим интерфейсом - PullRequest
Новая
       6

Стратегия ведения журнала для программы с графическим интерфейсом

3 голосов
/ 23 октября 2010

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

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

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

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

Ответы [ 2 ]

5 голосов
/ 05 ноября 2010

Как уже было сказано, вы можете использовать модуль логгера. Вы можете установить уровень ведения журнала по умолчанию (например, Предупреждение) и поместить все виды сообщений в ваш код, начиная с отладки до критического состояния. В качестве скромного объяснения, если вы установите уровень ведения журнала как «Предупреждение», даже если сообщения отладки журнала кода не будут отображаться в файле (или в 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: 

magun@~: 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!
magun@~:

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

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)

В этом случае я использовал файл журнала с максимальным размером 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 байт.

Посмотрите, что произошло: 

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

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

0 голосов
/ 23 октября 2010
...