Искусство отладки

Цель лекции: Ознакомиться с особенностями отладки Django; рассмотреть понятие протоколирования и его особенностями; научиться использовать интерактивный отладчик; ознакомиться с отладочной панелью.

Ключевые термины: django, журнал, модуль, python ,панель, отладка, функция, протокол, файл, команда, код, path, фильтр, обработчик, трассировка

В этой лекции мы узнаем три вещи о веб-разработке на Django, которые должен знать каждый программист. Это концепции и техники, которые вам понадобятся, если что-то пойдем не так.

Протоколирование

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

Django использует базовое протоколирование Python, так что мы рассмотрим детально базовое протоколирование Python в следующем разделе и увидим, как мы можем использовать службу протоколирования для записи в файл отчета в Django.

Формальное определение протоколирования – это отслеживание событий программного обеспечения. Разработчики вызывают службу протоколирования, чтобы определить, что событие произошло или происходит. Протоколирование может содержать некоторое описание или значение какой-либо важной переменной, которое нужно отследить.

Модуль Python logging поставляется с пятью функциями для ведения файлов отчетов, которые распределены по категориям в зависимости от серьезности события. Это debug(), info(), warning(), error() и critical().

Они подразделяются на категории в порядке их серьезности (начиная от наименее серьезной до самой серьезной):

• debug(): используется при фиксации ошибок и обычно имеет подробную информацию о данных.
• info(): создает файл отчета, когда вещи работают, как они должны.В основном говорит о том, было ли выполнение успешно или нет.
• warning(): возникает при наступлении некоторых неожиданных событий. Это на самом деле не останавливает выполнение, но он может остановить выполнение в будущем. Например "недостаточно места на диске".
• error(): это следующий уровень предупреждения, которое гласит, что возможен останов выполнения некоторых функций.
• critical(): это самый высокий уровень любой функции протоколирования. Возникает в случае, когда очень серьезная ошибка может остановить выполнение всей программы.

Модуль logging делится на следующие четыре категории:

• Средства ведения журнала: Журнал является точкой входа для сообщения журнала системы. Программы записи протоколирования информации ведут файлы отчетов, которые затем обрабатываются вне зависимости, должен ли быть вывод на консоль или запись в файл.

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

Средства ведения журнала, сами имеют уровень регистрации, который работает так: если уровень регистраций сообщения журнала больше или равен уровню регистрации журнала, тогда сообщение будут обработано далее для протоколирования; в противном случае оно будет игнорироваться средством ведения журнала.

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

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

Так же, как средства ведения журнала, обработчики также имеют уровень регистрации. Сообщения журнала игнорируются обработчиком, если уровень регистрации записи журнала не больше или равен уровню обработчика.

Несколько обработчиков могут быть прикреплены к средству ведения журнала, например, может быть обработчик для ведения средства ведения журнала, которое отправляет сообщения ERROR и CRITICAL и по электронной почте, тогда как другой обработчик может записывать тот же самый журнал в файл для последующего анализа отладки.

• Фильтры: Фильтр добавляет дополнительную оценку, когда запись журнала передается от средства журналирования обработчику. Поведением по умолчанию является то, что он начинает обработку письма, когда уровень регистрации сообщения встречается с уровнем обработчика.

Это процесс может быть прерван для дополнительной оценки путем применения фильтра.

Например, фильтр разрешает только один источник для записи сообщения ERROR с обработчиком.

Фильтр также может использоваться для изменения приоритета записи журнала, так что средство журналирования и обработчик запускаются соответственно.

• Средства форматирования: Последним шагом перед тем, как сообщение журнала действительно будет запротоколировано, которое будет находиться в текстовом формате, является средство форматирования, фактически форматирует запись журнала, которая состоит из форматированных строк Python.

Чтобы включить ведение журнала в нашем приложении, мы сначала создадим средство ведения журнала. Нам нужно создать словарь регистрации в файле settings.py, который описывает средства журналирования, обработчики, фильтры и средства форматирования.

Полную документация о настройке ведения журнала можно найти на HTTPS://docs.Python.org/2/Library/Logging.config.HTML

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

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
    },
    'handlers': {
        'file':{
            'level':'DEBUG',
            'class': 'logging.FileHandler',
            'formatter': 'simple',
            'filename': 'logs/debug.log',
           }
    },
    'loggers': {
        'django': {
        'handlers':['file'],
        'propagate': True,
        'level':'INFO',
    },
    }
}

Этот журнал установки определяет один регистратор (Django), тот что нужен для запроса Django и обработчик (файл), который записывает в файл журнала с модулем форматирования.

Мы будем использовать то же самое для тестирования протоколирования для нашего проекта mytweet.

Теперь нам нужно сделать запись журнала в представлении, где мы хотим отслеживать событие.

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

Откройте файл tweet/view.py и измените класс UserRedirect в соответствии со следующим:

class UserRedirect(View):
    def get(self, request):
        if request.user.is_authenticated():
            logger.info('authorized user')
            return HttpResponseRedirect('/user/'+request.user.username)
        else:
            logger.info('unauthorized user')
            return HttpResponseRedirect('/login/')

Кроме этого, инициализируйте средство ведения журнала с помощью оператора import и добавьте следующий код для выполнения предыдущего кода:

import logging
logger = logging.getLogger('django')

Вот так. Теперь, откройте браузер и кликните по URL-адресу http://localhost:8000/prоfile.

Вы будете перенаправлены на страницу входа, если вы еще не вошли в систему.

Теперь откройте файл debug.log. Он содержит информацию о неавторизованном пользователе, это означает, что наш журнал прекрасно работает:

INFO unauthorized user