Использовали ли логирование ошибок на проекте и какие инструменты
Что проверяют
Работали ли вы с логами как с инструментом поиска проблем на проде, а не только как с выводом в консоль. Следом обычно просят рассказать конкретный инцидент: как узнали об ошибке, где искали причину и сколько времени ушло.
Как отвечать
Это вопрос про опыт, поэтому каркас строится на вашем проекте, а технологии служат опорой:
- API и реализация: SLF4J как фасад, под ним Logback (по умолчанию в Spring Boot) или Log4j2. В коде логгер из
LoggerFactory.getLogger(...)и плейсхолдеры{}вместо склейки строк; - исключения: исключение передаётся последним аргументом,
log.error("Не удалось провести платёж {}", paymentId, e), тогда в лог попадёт полный стектрейс; - контекст:
requestIdиuserIdкладут в MDC, а с Micrometer Tracing trace id попадает туда сам. Без этого строки одного запроса в общем потоке не собрать; - формат и сбор: JSON-логи (в Spring Boot начиная с 3.4 есть встроенный structured logging, раньше брали
logstash-logback-encoder), дальше ELK или OpenSearch, Loki с Grafana, Graylog; - трекинг ошибок: Sentry, в том числе self-hosted, группирует одинаковые исключения и присылает алерт на новую или участившуюся ошибку.
Дальше расскажите свою историю: что логировали, куда это уходило, как срабатывал алерт, и один реальный случай, где лог помог найти причину. Цифры берите свои (время до обнаружения, число инцидентов), придуманное «сократили время на 30%» слышно сразу. Если систему настраивали не вы, скажите об этом прямо: вы пользовались Kibana или Grafana и писали логи по принятым правилам. Тогда объясните, что это были за правила и зачем они.
Где спотыкаются
Пишут log.error(e.getMessage()) или e.printStackTrace(). Стектрейс теряется или уходит мимо системы логирования.
Логируют и пробрасывают исключение дальше на каждом уровне. Одна ошибка превращается в пять записей, и алерты тонут в шуме.
Пишут в лог пароли, токены и персональные данные. Это утечка через систему, к которой доступ есть у многих, и прямое нарушение требований 152-ФЗ.