Какие уровни логирования используются

Что проверяют

Понимаете ли вы, чем уровни отличаются по смыслу, а не только по названию, и знаете ли, зачем они нужны в эксплуатации.

Как отвечать

Стандартный набор по возрастанию серьёзности:

• TRACE: подробнейшая трассировка, каждый шаг. Включают точечно и ненадолго;
• DEBUG: значения переменных, ветвления, полезные для разбора. В проде обычно выключен;
• INFO: значимые события нормальной работы: сервис поднялся, задача выполнена, заказ создан;
• WARN: что-то пошло не так, но система справилась. Повтор запроса удался, значение взято из кэша, приблизился лимит;
• ERROR: операция не выполнена, нужен разбор. Обязательно со стеком и контекстом;
• FATAL (не везде): приложение не может продолжать работу.

Практика, которая отличает опытного:

• уровень задаёт объём: в проде обычно INFO, а DEBUG включают на время разбора, желательно без перезапуска;
• структурные логи: JSON с полями (идентификатор запроса, пользователь, длительность) вместо строк, иначе поиск превращается в регулярки;
• сквозной идентификатор запроса, иначе в микросервисах невозможно собрать одну историю;
• в логи не попадают секреты и персональные данные;
• ошибка логируется один раз, на границе, где её обработали, а не на каждом уровне стека.

Для тестировщика логи это первый источник доказательства в отчёте о дефекте: приложить фрагмент лога с идентификатором запроса надёжнее, чем описать словами.

Где спотыкаются

Логируют всё уровнем ERROR, из-за чего настоящие ошибки тонут.

Пишут catch с логом и продолжают выполнение, будто ничего не случилось.

Логируют исключение на каждом уровне и получают одну ошибку пять раз.

Оставляют DEBUG в проде и раздувают объём в десятки раз.