Использовали ли вы Logback для логирования в Java-проекте?

А, Logback, говоришь? Ну да, использовал, конечно, блядь. Это ж как тот самый надёжный друг, который всегда на подхвате, когда приложение начинает творить хуйню и надо понять, в каком именно месте оно ебнулось. Современный такой наследничек Log4j, только шустрее и умнее, ёпта.

Слушай, главная его фишка — это то, что он обычно под капотом у SLF4J работает. Это как если бы у тебя был универсальный пульт от всех телевизоров, а Logback — это самый крутой телик в доме. Подключаешься через фасад, а внутри уже эта зверюга всё пилит.

Чем он всех так ебёт, спросишь?

• Быстрый, сука, как ужаленный. Накладные расходы — минимальные, не то что некоторые.
• Конфигурируется через logback.xml — гибко, мощно, можно такие фортели вытворять.
• Может перечитывать конфиг на лету, не перезагружая всю прогу. Добавил условие — он уже работает. Магия, блядь!
• Куда писать — да куда угодно, ёпта! В файл (с ротацией, чтоб не сожрал всё место), в консоль, в базу, хоть в космос. Аппендеры на любой вкус.
• Фильтры и асинхронность — это вообще песня. Можно отсеивать мусор и писать логи в отдельном потоке, чтобы основное приложение не тормозило.

Вот, смотри, как обычно этот цирк в logback.xml выглядит:

<configuration>
    <!-- Это чтобы в файл писал, да ещё и старые логи по датам архивировал -->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>myapp.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>myapp.%d{yyyy-MM-dd}.log</fileNamePattern>
            <maxHistory>30</maxHistory> <!-- Храним 30 дней, а дальше — нахуй -->
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <!-- А это для красивого вывода в консольку, с цветами чтоб -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss} %highlight(%-5level) %logger{20} - %msg%n</pattern>
        </encoder>
    </appender>

    <!-- Корневой логгер: INFO и выше летят и в файл, и в консоль -->
    <root level="INFO">
        <appender-ref ref="FILE" />
        <appender-ref ref="CONSOLE" />
    </root>
    <!-- А для своего сервиса включаем дебаг, чтобы видеть всю подноготную -->
    <logger name="com.mycompany.service" level="DEBUG" />
</configuration>

А в коде это выглядит просто, как палка:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyService {
    // Создаёшь логгер для своего класса — и всё, понеслась
    private static final Logger log = LoggerFactory.getLogger(MyService.class);

    public void processOrder(Order order) {
        log.info("Начало обработки заказа ID={}", order.getId()); // Инфо — для истории
        try {
            // делаем дела
            log.debug("Промежуточное состояние: {}", order.getStatus()); // Дебаг — для разбора полётов
        } catch (Exception e) {
            // А вот если всё пошло по пизде — тут уже error с полным стектрейсом
            log.error("Ошибка при обработке заказа {}: {}", order.getId(), e.getMessage(), e);
        }
    }
}

А ещё там, блядь, есть приколы на любой вкус:

• Условия в конфиге (<if>) — типа, если переменная окружения DEBUG=true, то включаем дебаг. Умно, сука!
• Через JMX настройки менять можно прямо в рантайме. Увидел аномалию — поднял уровень логирования, не перезапуская сервис. Красота!
• Маркеры (Markers) — это такая хитрая жопа, чтобы помечать особо важные логи, например, все запросы от конкретного пользователя, и потом их легко выцепить.

В общем, инструмент — огонь. Надёжный, быстрый, гибкий. Когда разберёшься с конфигом, кажется, что можешь вообще всё. Главное — не закопаться в нём и не начать логировать каждое движение курсора, а то логов будет овердохуища.