Python: Веб-разработка (Flask)
2026-02-26 17:10 Diff
https://ru.hexlet.io/courses/python-flask/lessons/logging/theory_unit

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

Возьмем для примера типичный сайт. Что он в себя включает?

  • DNS - система трансляции имени сайта в ip-адрес сервера.
  • Веб-сервер - программа, обслуживающая входящие запросы, перенаправляет их в код приложения и забирает от приложения данные для пользователей.
  • Физический сервер (или виртуальный) с его окружением - включает в себя операционную систему, установленные и запущенные обслуживающие программы, например, мониторинг.
  • База данных - внешнее хранилище, с которым связывается код приложения и обменивается информацией.
  • Само приложение - помимо кода, который пишут программисты, приложение включает в себя сотни тысяч и миллионы строк кода сторонних библиотек. Кроме этого, код работает внутри фреймворка, у которого свои собственные правила обработки входящих запросов.
  • Фронтенд часть - код, который выполняется в браузере пользователя. И системы сборки для разработки, например, Webpack.

И это только самый простой случай. Реальность же значительно сложнее: множество разноплановых серверов, системы кеширования (ускорения доступа), асинхронный код, очереди, внешние сервисы, облачные сервисы. Все это выглядит как многослойный пирог, внутри которого где-то работает написанный нами код. И этот код составляет лишь небольшую часть всего происходящего. Как в такой ситуации понять, на каком этапе был сбой, или все пошло не по плану? Для этого, как минимум, нужно определить, в каком слое произошла ошибка. Но даже это не самое сложное. Об ошибках в работающем приложении узнают не сразу, а уже потом, — когда ошибка случилась и, иногда, больше не воспроизводится.

Логирование

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

Выше небольшой кусок лога веб-сервера Хекслета. Из него видно ip-адрес, с которого выполнялся запрос на страницу и какие ресурсы загружались, метод HTTP, ответ бекенда (кода) и размер тела ответа в HTTP. Очень важно наличие даты. Благодаря ей всегда можно найти лог за конкретный период, например на то время, когда возникла ошибка. Для этого логи "грепают" (слово пошло от консольного приложения grep), то есть ищут по ним запись:

Когда программисты только начинают свой путь, они, часто не зная причину ошибки, опускают руки и говорят «я не знаю, что случилось, и что делать». Опытный же разработчик всегда первым делом говорит «а что в логах?».Анализировать логи — один из базовых навыков в разработке. В любой непонятной ситуации нужно смотреть логи. Логи пишут все программы без исключения, но делают это по-разному и в разные места. Чтобы точно узнать, куда и как, нужно идти в документацию конкретной программы и читать соответствующий раздел документации.

Flask использует встроенный модуль logging. Все сообщения логируются объектом app.logger. Чтобы записать в лог сообщение, его нужно передать в один из его методов:

По умолчанию логи выводятся в консоль:

Обратите внимание на методы логера: debug(), info(), warning(), error(). Каждый из методов добавляет сообщение своего уровня логирования.

Уровни логирования

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

  • debug
  • info
  • warning
  • error
  • critical

У уровней есть также порядок их серьезности:

DEBUG < INFO < WARNING < ERROR < CRITICAL

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

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

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

Во Flask по умолчанию используется уровень warning. При таком уровне будут выводиться и warning, и error. Если поставить уровень error, то будут выводиться только ошибки. А если debug, то мы получим лог, максимально наполненный данными. Обычно debug приводит к многократному росту выводимой информации.

Регулировать уровень выводимых логов можно через параметр setLevel(logging.<LEVEL>):

Теперь будут выводиться сообщения от уровня info и выше:

Ротация логов

Со временем количество логов становится большим, и с ними нужно что-то делать. Для этого используется ротация логов. Иногда за это отвечает сама программа, но чаще — внешнее приложение, задачей которого является чистка. Эта программа по необходимости разбивает логи на более мелкие файлы, сжимает, перемещает и, если нужно, удаляет. Подобная система встроена в любую операционную систему для работы с логами самой системы и внешних программ, которые могут встраиваться в нее.

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

Здесь тоже есть несколько путей. Можно воспользоваться готовыми решениями, такими как DataDog Logging, либо устанавливать и настраивать все самостоятельно через, например, ELK Stack

Заключение

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