Ведение журнала является критическим фактором, который следует всегда учитывать при разработке программного обеспечения.
Когда в работе происходит что-то плохое, файлы журнала обычно являются отправной точкой нашего анализа ошибок. И часто они являются единственной информацией в наших руках, чтобы понять, что произошло, и что является основной причиной проблемы.
Очень важно правильно зарегистрировать необходимую информацию.
Следующие пять правил ведения журналов — это способ проверить и, возможно, улучшить способ обработки журналирования в нашем коде.
Обратите внимание, что мы не будем обсуждать, как настроить механизм ведения журнала, и не будем сравнивать их друг с другом.
Правило 1. Логирование для читателей
Сообщения регистрации должны иметь смысл для того, кто будет читать файлы журнала , а не только для того, кто написал код (запись в журнал).
Это кажется очень очевидным правилом, но оно часто нарушается.
Например, давайте рассмотрим сообщение журнала, подобное следующей ERROR: Save failure - SQLException .....
Сохранение чего? Это сообщение может что-то значить для разработчика, но оно совершенно бесполезно для бедного парня, который смотрит на производственную проблему.
Намного лучше сообщение ERROR: Save failure- Entity=Person, Data=[id=123 surname="Mario"] - SQLException....
который объясняет, что вы хотели сохранить (здесь Person, сущность JPA) и соответствующее содержимое экземпляра Person. Обратите внимание на слово релевантное , а не на весь мир: мы не должны загромождать лог-файлы бесполезной информацией, такой как полная печать всех полей сущностей. Имя сущности и ее логические ключи обычно достаточно для идентификации записи в таблице.
Правило 2. Сопоставьте уровни ведения журнала со средой выполнения
Все фасады и механизмы ведения журнала, доступные в экосистеме Java, имеют концепцию уровня ведения журнала (ОШИБКА, ИНФОРМАЦИЯ …) с возможностью отфильтровывать сообщения со слишком низким уровнем.
Например, в журнале утилит Java используются следующие уровни: SEVERE, WARN, INFO, FINE, FINER, FINEST (+ CONFIG и OFF).
Напротив, два самых популярных фасада регистрации, Apache Commons Logging и SLFJ , предпочитают следующие уровни: FATAL, ERROR, WARN, INFO, DEBUG, TRACE.
Фильтрация по уровню ведения журнала должна зависеть от того, на каком этапе разработки находится ваш код: уровень ведения журнала в производственной среде не должен быть таким же, как в средах тестирования / интеграции.
Кроме того, уровень ведения журнала также должен зависеть от владельца кода. В целом наш собственный код приложения должен иметь более подробное ведение журнала по сравнению с любой сторонней библиотекой, которую мы используем. Нет большого смысла видеть, например, отладочные сообщения Apache Commons в наших файлах журналов.
Я обычно настраиваю регистрацию следующим образом:
- Производство : уровень INFO для моего кода и WARN для сторонних библиотек.
- Тест / интеграция : уровень DEBUG для моего кода и WARN (или INFO, если необходимо) для сторонних библиотек.
- Развитие : все, что имеет смысл
Примечание: я лично не рекомендую использовать уровень TRACE / FINEST (и я не одинок, см., Например, здесь ). Я не вижу большой разницы между DEBUG и TRACE, и молодым членам команды обычно трудно решить, какой из них, DEBUG или TRACE, использовать. Следуя принципу Kiss , я предлагаю использовать только уровни ERROR, WARN, INFO и DEBUG.
Правило 3. Удалите запись справки по кодированию перед фиксацией.
Во время кодирования мы обычно добавляем сообщения регистрации, используя logger или System.out , в наш код для лучшего понимания того, что происходит в нашем приложении во время сеансов выполнения / отладки.
Что-то типа:
|
1
2
3
4
5
|
void aMethod(String aParam) { LOGGER.debug(“Enter in aMethod”); if (“no”.equals(aParam)) { LOGGER.debug(“User says no”); …. |
Основная цель этих сообщений — отслеживать поведение приложения, показывая, какой метод вызывается, и сбрасывая внутренние переменные и значения параметров метода. Довольно популярен среди не-поклонников TDD.
К сожалению, эти сообщения обычно не имеют большого значения после выпуска кода (для тестирования и последующего производства).
Таким образом, это правило просто гласит: как только вы закончите разработку, удалите все временные и ненужные сообщения регистрации непосредственно перед передачей кода в используемую систему SCM (git, svn ..).
Это правило не требует удаления всех сообщений DEBUG, а только тех, которые не имеют значения после завершения и выпуска приложения; другими словами, когда мы достаточно уверены, что приложение работает должным образом.
Правило 4: проверяйте уровень журнала перед регистрацией сообщений DEBUG
В соответствии с правилом 2 в производственных журналах мы будем показывать только сообщения ERROR, WARN, INFO, но в нашем коде мы можем иметь много сообщений DEBUG, которые не должны влиять на производственное выполнение.
Каждый раз, когда вы хотите зарегистрировать сообщение DEBUG (все, которые остаются после правила 3), добавьте перед ним проверку, если включено ведение журнала DEBUG:
|
1
2
3
|
if ( LOGGER.isDebugEnabled() ) { LOGGER.debug (…….) } |
Это предотвратит ваш код для создания сообщений журнала и вызова регистратора. Это для эффективности в выполнении программы на производстве.
Правило 5: Знай своего регистратора
То, как мы используем методы ведения журнала, может иметь значительные затраты:
- Чтобы построить строку сообщения
- собирать данные для включения в строку сообщения
Мы должны рассмотреть javadoc выбранного фасада / движка регистрации и понять, как наиболее эффективно использовать его регистратор.
Например, мы могли бы создать сообщение как это:
|
1
|
LOGGER.info(“Person name is “ + person.getName()); |
который создает ненужные экземпляры строк.
Используя SLF4J, правильное использование:
|
1
|
LOGGER.info(“Person name is {}“, person.getName()); |
где строка формата постоянна, а окончательное сообщение формируется, только если включено ведение журнала. Смотрите здесь для более подробной информации.
| Ссылка: | 5 правил ведения журнала Java от нашего партнера по JCG Гуальтьеро Теста в блоге Гуалтиеро Теста . |