[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-logirovanie-kakie-est-luchshie-praktiki-logirovaniya":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},1303,"kakie-est-luchshie-praktiki-logirovaniya",43,"logirovanie","Логирование","📝","Какие есть лучшие практики логирования?","Хорошее логирование — это баланс между достаточностью информации для диагностики и отсутствием шума. Логи должны быть полезны через 3 месяца, когда контекст забыт.\n\n### Что логировать\n\n- Начало и завершение значимых бизнес-операций\n- Ошибки и исключения (с полным стек-трейсом)\n- Входящие запросы (метод, URL, ключевые параметры)\n- Интеграционные вызовы (к другим сервисам, БД, очередям)\n- Изменения состояния (статус заказа, роль пользователя)\n\n### Что НЕ логировать\n\n- Пароли, токены, API-ключи, секреты\n- Персональные данные (PII): номер карты, СНИЛС, паспорт\n- Тела запросов\u002Fответов целиком (могут содержать sensitive данные и быть огромными)\n\n### Как логировать правильно\n\n```java\n\u002F\u002F ПРАВИЛЬНО — параметризованные сообщения\nlog.info(\"Пользователь {} авторизован, роль: {}\", userId, role);\n\n\u002F\u002F НЕПРАВИЛЬНО — конкатенация (выполняется всегда)\nlog.debug(\"Результат: \" + expensiveOperation());\n\n\u002F\u002F ПРАВИЛЬНО — исключение как последний аргумент (стек-трейс автоматически)\nlog.error(\"Ошибка обработки заказа {}\", orderId, exception);\n\n\u002F\u002F НЕПРАВИЛЬНО — стек-трейс потерян\nlog.error(\"Ошибка: \" + exception.getMessage());\n\n\u002F\u002F ПРАВИЛЬНО — проверка уровня для дорогих операций\nif (log.isDebugEnabled()) {\n    log.debug(\"Детали: {}\", computeExpensiveDebugInfo());\n}\n```\n\n### Гайд по выбору уровня\n\n| Уровень | Когда использовать | Пример |\n|---------|-------------------|--------|\n| ERROR | Требуется реакция (алерт) | Сервис недоступен, данные повреждены |\n| WARN | Потенциальная проблема, система справилась | Retry succeeded, deprecated API, fallback |\n| INFO | Нормальные бизнес-события | Заказ создан, пользователь авторизован |\n| DEBUG | Диагностика для разработчика | SQL, промежуточные данные, состояние кэша |\n| TRACE | Максимальная детализация | Вход\u002Fвыход из метода, значения переменных |\n\n### Золотые правила\n\n- Один запрос = одна корреляция: всегда логируйте requestId\u002FtraceId для связывания записей\n- Исключение — ВСЕГДА последним аргументом: `log.error(\"msg\", arg1, exception)`\n- В production: INFO + structured JSON + correlation ID\n- Не логируйте в цикле — 10 000 итераций по одному логу = 10 000 записей; агрегируйте результат\n- Не делайте catch + log + throw — двойное логирование; логируйте на верхнем уровне\n\n### Частые ошибки\n\n- `log.error(exception.getMessage())` — теряется стек-трейс; используйте `log.error(\"msg\", exception)`\n- Логирование в цикле без агрегации — замедляет систему и засоряет логи\n- Catch + log + throw — одно исключение логируется дважды\n- ERROR для всех исключений — `NotFoundException` при `GET \u002Fusers\u002F999` — это не ERROR, а INFO или WARN\n\n### Как используется в 2026\n\n- Lombok `@Slf4j` — автоматическая генерация `private static final Logger log`\n- IDE (IntelliJ) — live templates `logi`, `logd`, `loge` для быстрого логирования\n- Spring Boot Actuator — динамическое изменение уровней через HTTP\n\n> **На собеседовании:** перечислите конкретные антипаттерны: потеря стек-трейса через `getMessage()`, логирование в цикле, catch-log-throw. Это показывает production-опыт. Частая ошибка — дать абстрактный ответ \"логируйте всё важное\" без конкретных примеров.","","middle",[15],"logging",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":23,"featuredSnippetReady":24},"Какие есть лучшие практики логирования? — Gymterview","Хорошее логирование — это баланс между достаточностью информации для диагностики и отсутствием шума. Логи должны быть полезны через 3 месяца, когда контекст заб","Хорошее логирование — это баланс между достаточностью информации для диагностики и отсутствием шума. Логи должны быть по",[15,13],"Хорошее логирование — это баланс между достаточностью информации для диагностики и отсутствием шума. Логи должны быть полезны через 3 месяца, когда контекст забыт.",true]