Сегодня мы обсудим, зачем кому-то понадобилось писать замену стандартному питонячему логеру logging и как этой штукой пользоваться.



Больновато!


Когда заходит речь о логировании в Python, на ум сразу приходит logging.


logging — крепкое стабильное решение, плотно вшитое в экосистему Python. Импортишь его куда надо, производишь пару манипуляций — и все, вроде как можно писать заветное logger.exception('што-то-там'). И запись 'што-то-там' попадет в какой-то журнал.


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


Появляются конфиги для логгера, которые начинаются с громоздкого, но более-менее понятного:


LOGGER_CONFIG = {
  "version": 1,
  "disable_existing_loggers": False,
  "formatters": {
    "simple": {
      "format": "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
    }
  },
  "handlers": {
    "console": {
       "class": "logging.StreamHandler",
       "level": "DEBUG",
       "formatter": "simple",
       "stream": "ext://sys.stdout"
    },
  },
 "root": {
    "level": "INFO",
    "handlers": ["console"]
  }
}

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


Чтобы не больно и даже приятно


Однажды пара программеров окончательно задолбалась копаться (и ошибаться) во многочисленных настроечных опциях logging. Эти инженеры написали свой логгер, предельно простой и при этом очень мощный. Называется эта штука Loguru.


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



Почему стоит рассмотреть loguru в качестве альтеранативы logging?


  • Простота. Про это я уже сказал выше, но скажу еще раз — грамотно настроить loguru проще, чем logging.
  • Понятные способы настройки ротации файлов журналов и архивации старых записей.
  • Кучи батареек уже включены в коробку — цвета сообщений, форматирование, отсылка уведомлений о сбоях на почту, стеки вызовов функций вместе с краш-репортами и много других няшных приятностей.
  • И, конечно же, асинхронность! Да-да, мир Python едет все дальше в сторону async/await, и этот тектонический сдвиг всего питонячего программирования явно требует асинхронных логеров.

Конечно, за все надо платить. И за использование loguru придется платить двумя вещами:


  • Либа относительно молода и могут быть неожиданности.
  • Авторы обещают полную совместимость с logging, но вы вполне можете натолкнуться на проблемы стыковки loguru с библиотеками от третьи лиц для logging. Например, при навешивании обработчиков для Sentry или Airbrake.

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

Комментарии (8)


  1. laviol
    06.06.2019 12:13

    Когда идет сравнение утилит в пользу какой-то конкретной, хотелось бы видеть примеры того, чем предлагаемое решение лучше альтернатив.
    Из статьи я так и не понял, в чем же простота настройки Loguru по сравнению с logging, чем этот процесс отличается?
    Фишки, описанные в пунктах статьи (те же краш репорты со стеками вызовов, асинхронность) — где хоть какая-то иллюстрация? Демка это конечно здорово и приятно, но недостаточно и, к сожалению, не информативно.
    Я понимаю, что я могу зайти на сайт Loguru и сам все это выяснить, но в таком случае зачем нужна данная статья?


    1. 57uff3r Автор
      06.06.2019 12:26
      +2

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


  1. devpony
    06.06.2019 13:02
    +1

    Очень круто! И coverage 100% радует. Попробуем по возможности.


  1. zyrik
    06.06.2019 19:11

    Уже постоянно использую в своих собственных проектах. Основной плюс, который заметил на данный момент, это нормальная работа в multithreading/multiprocessing конфигурациях. До этого со стандартным logging я постоянно терял что-то из других потоков/процессов.


  1. worldmind
    06.06.2019 19:56
    +1

    Думаю люди просто не осилили конфигуть syslog и другие fluentd'ы, ибо все эти ротации, раскладывания по файлам это не задача логгера, логгер просто должен вызвать API и забыть, а всё остальное включая перенос логов на лог-сервер должно делать специальное решение и их тьмы.


    1. worldmind
      06.06.2019 19:58

      и тогда весь конифиг выглядит как-то так:

      ---
      version: 1.0
      disable_existing_loggers: False
      
      formatters:
          syslog:
              format: '%(levelname)s %(module)s.%(funcName)s: %(message)s'
      
      handlers:
          syslog:
              class: logging.handlers.SysLogHandler
              formatter: syslog
              level: INFO
              address: /dev/log
      
      root:
          level: INFO
          handlers: [syslog]


    1. 57uff3r Автор
      07.06.2019 15:28

      Такие логгеры, конечно, для промышленного сбора записей ну никак не подходят. Пожалуй, их сфера применения – небольшие проекты и программы в стадии разработки, в которых нужно быстро что-то на коленке записать. А так серъезным парням, конечно, надо ELK или что-то такое же монструозное )


      1. worldmind
        07.06.2019 15:33

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