Стандартный logging остаётся базой — им пользуются все фреймворки и библиотеки, и через него проходит интеграция с OpenTelemetry. Но конфигурация через dictConfig не самая удобная, а контекст на уровне запроса приходится прокидывать вручную через contextvars.
structlog — главный кандидат на замену. Процессорный pipeline из коробки даёт redaction, enrichment и sampling. contextvars работают через asyncio без дополнительного кода. При этом можно оставить stdlib на бэке — вся хэндлер-экосистема сохраняется. По бенчмаркам structlog примерно в 2 раза быстрее stdlib и Loguru: 242k ops/s против 139k и 147k соответственно.Loguru — минимум setup, но ценой глобального логгера без иерархии компонентов. Нет нативной OpenTelemetry-интеграции, только через InterceptHandler в обход.Logbook — legacy от Armin Ronacher. Нет structured JSON из коробки, нет OTel. Для новых проектов не рекомендуется.picologging — drop-in replacement на C от Microsoft, в 4–17 раз быстрее, но проект не поддерживается с 2023 года, нет поддержки Python 3.13+. Не для продакшена.Главный вывод статьи: выбор библиотеки менее важен, чем практики. Structured output, консистентный контекст, правильные уровни и чистота полей — вот что делает логи полезными в production. Если stdlib с python-json-logger работает, не мигрируйте ради миграции. Если boilerplate мешает — берите structlog.
@zen_of_python