Ведение журнала — это процесс отслеживания и записи ключевых событий, происходящих в наших приложениях. Мы хотим регистрировать события, чтобы мы могли использовать их для проверки процессов, устранения проблем и т. д. Они намного мощнее, чем операторы print, потому что они позволяют нам отправлять определенные фрагменты информации в определенные места, не говоря уже о пользовательском форматировании, общий интерфейс с другими пакетами Python и т. д. Это делает ведение журнала ключевым сторонником возможности получения полезной информации из внутренних процессов нашего приложения.

Компоненты

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

  • Logger: основной объект, который генерирует сообщения журнала из нашего приложения.
  • Handler: используется для отправки записей журнала в определенное место и спецификаций для этого места (имя, размер и т. д.).
  • Formatter: используется для стиля и расположения записей журнала.

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

Уровни

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

Давайте определим уровни журнала, используя базовые конфигурации:

import logging 
import sys
#Create super basic logger
logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
#logging levels(from lowest to highest priority)
logging.debug("Used for debugging your code.")
logging.info("Informative messages from your code.")
logging.warning("Everything works but there is something to be aware of.")
logging.error("There's been a mistake with the process.")
logging.critical(There is something terribly wrong and process may terminate.")

Это базовыеуровни ведения журнала, где DEBUG — самый низкий приоритет, а CRITICAL — самый высокий. Мы определили наш регистратор с помощью basicConfig для отправки сообщений журнала в нашу консоль стандартного вывода (мы также могли записывать в любой другой поток или даже файл) и быть чувствительным к сообщениям журнала, начиная с уровня DEBUG. Это означает, что все наши зарегистрированные сообщения будут отображаться, поскольку DEBUG является самым низким уровнем. Если бы мы сделали уровень, то отображались бы только сообщения журнала ERROR и CRITICAL.

Конфигурация

Рекомендуется указать, куда будут записываться наши журналы. Хорошо создать отдельный logs каталог, который является частью файла .gitignore, чтобы он не записывался в git.

Ниже приведен пример конфигурации регистраторов:

#Logger
logging_config = {
      "version": 1,
      "disable_existing_loggers": False,
      "formatters": {
          "minimal": {"format": "%(message)s"}'
          "detailed":{
              "format": "%(levelname)s %(asctime)s [%(filename)s:%(funcName)s:%(lineno)d]\n%(message)s\n"
          },
      },
      "handlers": {
          "console": {
              "class": "logging.StreamHandler",
              "stream": sys.stdout,
              "formatter": "minimal",
              "level": logging.DEBUG,
      },
      "info": {
          "class": "logging.handlers.RotatingFileHandler",
          "filename": Path(LOGS_DIR, "info.log"),
          "maxBytes": 10485760, # 1 MB
          "backupCount": 10,
          "formatter": "detailed",
          "level": logging.INFO,
      },
      "error": {
          "class": "logging.handlers.RotatingFileHandler",
          "filename": Path(LOGS_DIR, "error.log"),
          "maxBytes": 10485760, # 1 MB
          "backupCount": 10,
          "formatter": "detailed",
          "level": logging.ERROR,
      },
   },
   "loggers": {
       "root": {
           "handlers": ["console", "info", "error"],
           "level": logging.INFO,
           "propagate": True,
      },
   },
}
  1. Первая часть: определите два разных Formatters (определяют формат и стиль сообщений журнала), минимальный и подробный, которые используют различные атрибуты LogRecord для создания шаблона форматирования сообщений журнала.
  2. Вторая часть: определите разные обработчики (подробности о том, куда отправлять сообщения журнала):
  • console: отправляет сообщения журнала (используя средство форматирования minimal) в поток stdout для сообщений выше уровня DEBUG.
  • info: отправлять сообщения журнала (используя средство форматирования detailed) в logs/info.log (файл, который может иметь размер до 1 MB, и мы создадим резервную копию его последних 10 версий) для сообщений выше уровня INFO.
  • error: отправлять сообщения журнала (используя средство форматирования detailed) в logs/error.log (файл, который может иметь размер до 1 MB, и мы создадим резервную копию его последних 10 версий) для сообщений выше уровня ERROR.

3. Третья часть: прикрепляем к нашему Логгеру наши разные обработчики.

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

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

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