Как правильно логировать в бэкенд-сервисе?
- Какие бывают уровни логирования?
- Что такое структурированные логи?
Логи — события, по которым потом разбирают проблему. Уровни: ERROR — что-то сломалось и требует внимания, WARN — подозрительно, но работаем, INFO — значимые бизнес-события (заказ создан), DEBUG — подробности для отладки, в проде обычно выключены. Писать структурированно (JSON с полями: время, уровень, сообщение, request_id, user_id) в stdout, чтобы сборщик логов мог искать и фильтровать. Не логировать пароли, токены, номера карт и лишние персональные данные.
- request_id сквозной для всех сервисов — склеивает историю одного запроса
- Исключение логируют со стеком один раз, а не на каждом уровне
- Логи — не метрики: считать частоту лучше метриками
А ещё Плохой лог: «Ошибка». Хороший: «оплата не прошла: order_id=42, provider=X, code=insufficient_funds»
Подробно
Пример (Python):
log.info("order_created", extra={"order_id": order.id,
"user_id": user.id,
"amount": order.total})Вывод:
{"ts":"2026-10-13T10:00:00Z","level":"INFO","msg":"order_created",
"order_id":42,"user_id":7,"amount":1990,"request_id":"a1b2"}Объём: логировать на границах (вход запроса, вызов внешнего сервиса, ошибка), а не каждую строку — иначе логи дорого хранить и сложно читать.
Что хотят услышать
- Уровни логирования.
- Структурированные логи в stdout.
- request_id и контекст.
- Не логировать секреты и ПДн.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Логировать пароли и токены, чтобы было проще отлаживать вход
- ✗Писать только сообщение «Ошибка» без лишнего контекста
- ✓Структурированные логи с уровнями и контекстом (request_id) в stdout, без секретов
- ✗Постоянно включать DEBUG в продакшене для всех запросов
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.