Что такое система логирования?

А, слушай, про логирование! Ну это ж, ёпта, как дневник для твоего приложения, только вместо «сегодня видел красивую девочку» там «пользователь с ID 228 получил 500-ю ошибку, потому что БД накрылась медным тазом».

Ключевые штуки, которые надо понимать:

• Уровни логирования (Log Levels): Это типа приоритеты для твоих записей. От «ничего страшного» до «всё пиздец, вызывайте пожарных».
  • TRACE / DEBUG — для полных дебаг-дегенератов, которые хотят знать, какая именно переменная на каком микрочипе сейчас дернулась. В продакшене это включать — самоубийство, овердохуища текста будет.
  • INFO — нормальные рабочие моменты. «Сервис стартанул», «Юзер Вася залогинился». Скучно, но надо.
  • WARN — предупреждение. «Э, дружок-пирожок, память на 95% заполнена, скоро будет весело». Игнорируешь — сам потом виноват.
  • ERROR — вот тут уже конкретная ошибка, но приложение вроде не умерло. «Не смог отправить письмо, SMTP-сервер послал нас нахуй». Надо смотреть.
  • FATAL / CRITICAL — финальный аккорд. «База данных умерла и не дышит». Всё, приложение легло, пора бегать с криками «какого хуя?!».
• Appenders / Handlers: Куда эти логи сбрасывать. В консоль, в файлик (самое простое), в какую-нибудь навороченную систему, где их можно красиво искать. Если всё пихать в один файл и забыть, он вырастет до размеров, когда его открыть — уже подвиг.
• Форматеры (Layouts / Formatters): Как эта запись будет выглядеть. Просто текст «ошибка» — это пиздец как бесполезно. А вот если там дата, время, уровень, имя класса и трейс ошибки — уже можно работать. Без этого — волнение ебать, где искать причину.

Как это в QA используется, на практике:

1. Главный инструмент, когда тест падает. Автотест проёбался? Первый вопрос — «а что в логах?». Не «почему», а «что в логах?». Там stack trace, который покажет, в каком именно месте код решил, что жить дальше не стоит. Без логов дебажить — это как искать чёрную кошку в тёмной комнате, где её, сука, нет.
2. Иногда логи — часть проверки. Бывают операции, результат которых не так просто проверить через API или UI. Например, отправилось ли событие в аудит-систему. И тогда тест может тупо прочесть лог-файл и поискать там строчку «Событие X успешно отправлено». Если нашёл — ок. Не нашёл — вот тебе и баг.
3. Настройка уровня. Когда запускаю тестовый стенд, первым делом в конфигах ставлю уровень логирования на DEBUG. Потому что когда всё падает, нужно максимум информации, а не «ой, всё». А на боевом, конечно, INFO или WARN, иначе диск забьётся хламом за полчаса.

Вот, смотри, как это примерно в конфиге выглядит (Java, logback):

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>app.log</file> <!-- Вот сюда всё пойдёт -->
        <encoder>
            <!-- А вот так это будет выглядеть. Без pattern'а будет манда с ушами, одна строка на другой. -->
            <pattern>%d{HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="debug"> <!-- А вот тут уровень для всего приложения ставится -->
        <appender-ref ref="FILE" /> <!-- И говорим: «Пиши, сука, в этот файл» -->
    </root>
</configuration>

Короче, логи — это глаза и уши, когда приложение уже работает где-то там, в темноте. Без них ты слепой, и любая проблема превращается в квест «угадай, что сломалось». А с логами, если они нормально настроены, хотя бы видишь, где искать занозу.