Логирование ошибок в Django-проекте на боевом сервере

by Anton Chernousov aka GITA-DEV


Опубликовано: 02 Авг 2018 (последние правки 1 месяц, 2 недели)


Логирование ошибок в Django-проекте на боевом сервере

Как вы наверное знаете у Django Framework имеется отличная система отладки и вывода отладочной информации при ошибке WEB-приложения и включается режим отладки простым DEBUG = True. Естественно, что на продакшн (боевых) сервера такое поведение недопустимо и в случае сбоя клиенту отображается лишь страница 500 с соответствующим кодом возврата и конечно клиенту этого вполне достаточно, но нам то необходимо оперативно отреагировать на сбой web-приложения и принять меры.

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

Прежде всего нам необходимо настроить параметры SMTP-бэкенда, если у вас конечно не используется локальный MTA, для настройки бэкенда внести или измените в файле settings.py следующие параметры (естественно, что вам необходимо их изменить на ваши реальные данные):

EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_HOST = "mail.gita-dev.ru"
EMAIL_PORT = 465
EMAIL_USE_SSL = True
EMAIL_HOST_USER = "reports@gita-dev.ru"
EMAIL_HOST_PASSWORD = "xxxPasswordxxx"

Обратите внимание, что эти параметры являются параметрами по умолчанию для подсистемы работы с электронной почтой в Django.

Для настройки оповещений о сбоях вам достаточно задать два параметра (второй опционально):

ADMINS = [('Chernousov Anton', 'anton@gita-dev.ru')]
SEND_BROKEN_LINK_EMAILS=True

В первом параметре мы задаем список администраторов (сколько угодно), которые будут извещаться о сбоях на сервере, а второй параметр отвечает за логирование 404-х обращений (довольно бесполезная опция, для анализа 404-х лучше использовать лог Nginx).

С оповещениями по электронной почте вам думаю теперь все понятно и можем приступать к дополнительному логированию в текстовый файл. Для реализации этого функционала я добавил в config.py следующие параметры:

LOGGING = {
   'version': 1,
   'disable_existing_loggers': False,
   'handlers': {
       'file': {
           'level': 'DEBUG',
           'class': 'logging.FileHandler',
           'filename': '/var/log/web-portal.log',
       },
       'mail_admins': {
           'level': 'ERROR',
           'class': 'django.utils.log.AdminEmailHandler',
       },       
   },
   'loggers': {
       'django': {
           'handlers': ['file'],
           'level': 'DEBUG',
           'propagate': True,
       },
       'django.request': {
           'handlers': ['mail_admins'],
           'level': 'ERROR',
           'propagate': True,
       },              
   },
}

Для логирования в каталог /var/log/ соответствующий файл необходимо создать и назначить соответствующие права доступа (непревилегированный пользователь туда писать не может).

# touch /var/log/web-portal.log
# chown chernousov:chernousov /var/log/web-portal.log

Более подробно о логировании ошибок вы можете почитать в официальной документации к Django.



Обратите внимание на статьи:


Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Использование jQuery Ajax для отправки данных Django-форм без обновления WEB-страницы

Я последнее время довольно активно использую Java Script в своих проектах. 21-ый век все таки на дворе и надо соответствовать. Хотя почему то считается, что использовать чистый Ajax для работы с формами не стоит и необходимо предоставить возможность работы и с перезагрузкой страницы, но мне кажется, что врят ли сейчас кто-то пользуется IE6, ну и если и пользуется, это его персональное горе.


Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

Создание и публикация Django-приложения (Часть первая, создание типового Django-приложения)

Для тех кто знаком с Django-разработкой в этой статье вряд ли найдется, что то интересное, но для тех кто хотел бы понять как начать писать на Django/Python небольшие приложения думаю будет интересно, и дополнительно рассмотрим простой метод автоматизированного деплоя нашего приложения на продакшн-сервер. Эту статью я решил написать для самого себя в виде небольшой шпаргалки при запуске новых проектов, поэтому если что непонятно, пишите в комментариях и я попробую рассказать более подробно.


Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Отправка оповещений Django-приложения в приватный чат Rocket.Chat

Вчера я подумал, что если я все же вернулся к использованию Rocket.Chat и он меня уже не так бесит как предыдущие версии, то можно настроить систему оповещений о событиях на сайте и сбоях в работе Django-приложения в приватный чат Rocket.Chat. Для Python быстро нашелся вполне работоспособный модуль который идеально подошел для отправки сообщений в приватные чаты.


Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Запуск Web-приложений Django в Production-режиме (UWSGI/Nginx)

Django-приложения довольно сильно отличаются от php-приложений как структурой проекта, так и методом запуска.  Django-приложения по методу запуска больше похожи на Java, чем на PHP и классические ASP-проекты. Сегодня мы будем строить классическую связку из python-приложения и web-сервера Nginx обслуживающего реверс-проксирование запросов к приложению и предоставление файлов из каталогов media и static. LXC-изоляция в моем случае используется для поддержания python-окружения проекта и именно таким способом я предпочитаю изолировать проекты, а виртуальное окружение я предпочитаю не использовать, так как пару раз уже были проблемы при переносе Django-проектов.


Есть вопросы?
Спрашивайте и я обязательно вам отвечу!

* Поля обязательные для заполнения .

Блог это некоммерческий проект! Если вам понравился мой блог и то что я пишу помогло вам на практике, то можете сказать спасибо материально.