Организация журналов с log4j

Question

В настоящее время я работаю над демоном Linux, написанным на Java. Какова общая схема имен для журналов?

Прямо сейчас я имею в виду сделать что-то вроде:

DEBUG = /var/log/myapp.debug
INFO = /var/log/myapp.info
WARN = /var/log/myapp.warn
ОШИБКА = /var/log/myapp.err
FATAL = /var/log/myapp.err

Кто-нибудь есть какие-либо мнения/предложения по схеме именования? Я соглашусь с ответом, с которым я заканчиваю.

Надеюсь, этот вопрос не закрываются, так как есть и другие темы подобные, которые связаны мнение (как то, что IDE вы предпочитаете, и т.д.)

Answer 1

Я хотел бы использовать следующую схему приложений журналов:

/var/log/<app>/myapp.log 

Другими словами, все идет в один файл, независимо от уровня лог (есть уже достаточно сложности, когда у вас есть один журнал файл на один экземпляр в кластерных многоуровневых средах, больше нет необходимости).Обычно вы используете DEBUG во время разработки, ERROR для производства (иногда с другой схемой шаблонов для целей мониторинга, но это еще одна история). И уровень журнала может быть изменен по требованию для определенных регистраторов.

Answer 2

для Java-приложений, я рекомендую два бревна.

Первый - это stderr и stdout начала процесса. Настройте log4j для отправки ERROR и FATAL в CONSOLE, а также в FILE.

Второй журнал должен управляться log4j и включать все ошибки DEBUG - FATAL. Это будет подробный журнал, который вам понадобится для отладки сложных проблем. В вашем log4j настройте фильтры DEBUG и INFO, чтобы не показывать пакеты, которые вам не нужны. Например, вам, как правило, не требуется org.apache или org.jboss на уровне DEBUG.

Для структуры, я хотел бы сделать следующее:

/var/log/myapp/boot.log.$(date +%s) 
/var/log/myapp/server.log.$(date +%Y%m%d) 

У журнала server вращаются ежедневно, в то время как журнал загрузки создаст новый файл на каждом старте.

Не имеет смысла выделять DEBUG, INFO и т. Д. В свои собственные файлы журналов, поскольку вам обычно нужен контекст из разных уровней журнала, чтобы быть в одном файле.

Если вы не захватить журнал процесс stderr, вы не сможете захватить StackTrace с помощью kill -3, вы не увидите сообщения об ошибках системы, как Stale NFS handle, и вы не получите подробности Авария JVM.

Answer 3

Я настоятельно рекомендую вам использовать один журнал вместо нескольких, как вы предлагаете, потому что:

• выход журнала содержит достаточное количество информации (например, «[ERROR]») для фильтрации по уровню.
• Относительный порядок ведения отчетов на разных уровнях не может быть восстановлен (временная метка не включена) или не является тривиальной для восстановления (включая временную метку) при разделении на отдельные файлы по уровню.

Что касается количества регистрируемых событий, то это, вероятно, должно быть динамически настраиваемым (возможно, вы хотите использовать для этого файл конфигурации XML или Java)? WARN или ERROR - это разумный уровень ведения журнала, который будет использоваться по умолчанию. Во время разработки иногда полезно включать более мелкозернистый каротаж.