О логировании в java

#java #логирование

Приводится на хабре в статье библиотека Apache Commons Logging (не знаю смысл этой
библиотеки,  не юзал) и комментарий:


  За System.out.println для вывода логов начинающим программистам уже через неделю
обучения следует отрубать руки.


Так вот вопрос: а почему print настолько плох?

P.S. Сам я основы языка очень плохо знаю.
    

Ответы

Ответ 1

Логирование - это все-таки больше, чем вывод строк в консоль. Здесь имеют место следующие
параметры:


Цель: это может быть консоль (stdout), немного другая консоль (stderr), файл, удаленный
сервер сбора логов
Уровень логирования: для разных выводов может быть разный уровень вывода: например,
в один файл мы скидываем всё, но храним только последние десять мегабайт, а в другой
отправляем только сообщения уровня WARN и выше, но храним историю за последние шесть
месяцев
Per-package настройки: в случае, если "шалит" конкретный участок кода, можно включить
логирование только для него
Ротация логов: логи чаще всего надо хранить в файлах, которые нужно периодически
подчищать, и при этом во время проведения работ продолжать писать логи
Контекст выполнения: зачастую просто сообщения недостаточно (если транзакция провалилась,
то какие входные параметры этому поспособтсвовали?), поэтому существуют штуки типа
MDC, чтобы при обработке конкретного юзера перед каждым вашим сообщением добавлялась
мапа {processed user id: 12345}
Подстановка параметров: писать Logger.debug("Transaction #{} has failed with message
'{}'", transaction.getId(), e.getMessage()) гораздо удобнее, чем писать System.out.ptintln("Transaction
#" + transaction.getId() + " has failed with message '" + e.getMessage() + "'"). Кроме
удобства, это позволяет не конкатенировать строки, если уровень логирования выше самого
сообщения (т.е. при уровне INFO сообщения с уровнем DEBUG не будут тратить ресурсы
на конкатенацию) и группировать лог-сообщения по шаблону (искать в логах вместо просто
слова "transaction" конкретный шаблон).


Всем этим занимается библиотека логирования, и она сильно упрощает жизнь, когда нужно
перейти от одной модели к другой, например, когда логи возле приложения хранить стало
нецелесообразно, для переключения на удаленный сервер достаточно подключить новый аппендер
и перезапустить приложение. Кроме того, существует ситуация, когда логов настолько
много, что I/O не успевает справляться - о проблемах такого рода, как правило, не думают
вплоть до их появления, а в библиотеках (я надеюсь) некоторые предусмотрительные шаги
уже сделаны (например, logback совершенно точно по умолчанию пытается добавить сообщение
пять раз на тот случай, если что-то пошло не так).


Ответ 2

По сути, выше уже всё было сказано, добавлю ещё один практический аспект. Консоль
имеет определённую емкость. И, например, если она равна 300 строк, то в случае, если
в неё запишутся 500 строк, начальные 200 строк вы уже не увидите. Можно, конечно, увеличить
размер буфера консоли, но тогда придётся его увеличивать постоянно, а это не лучший
вариант. Особенно для большого проекта, где логи записываются практически непрерывно,
и логируется большой объём данных.