Как определить, какой уровень журнала использовать? - программирование
Подтвердить что ты не робот

Как определить, какой уровень журнала использовать?

Уровни журнала WARN, ERROR и FATAL довольно ясны. Но когда что-то DEBUG, а когда INFO?

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

Каковы критерии для определения уровней журнала?

4b9b3361

Ответ 1

Я не думаю, что есть какие-то жесткие правила; используя уровни типа log4j, мои "правила большого пальца" выглядят примерно так:

  • FATAL: приложение (или, по крайней мере, поток) вот-вот умрет ужасно. Здесь информация объясняет, почему это происходит.
  • ОШИБКА: что-то, что приложение делать не должно. Это не ошибка пользователя ( "недопустимый поисковый запрос" ); это ошибка утверждения, сетевая проблема и т.д. и т.д., вероятно, тот, который собирается прервать текущую операцию.
  • WARN: что-то, что касается, но не приводит к прекращению операции; количество подключений в пуле БД, низкий, необычный, но ожидаемый тайм-аут в операции и т.д. Я часто думаю о "WARN" как о полезном в совокупности; например grep, group и подсчитать их, чтобы получить представление о том, что влияет на состояние системы.
  • INFO: обычная регистрация той части нормальной работы приложения; так что вы можете вернуться назад и сказать "как часто происходит эта операция на широком уровне?" или "как данные пользователя попали в это состояние?"
  • DEBUG: отключено по умолчанию, может быть включено для отладки определенных непредвиденных проблем. Здесь вы можете зарегистрировать подробную информацию о параметрах ключевых методов или другой информации, которая полезна для поиска вероятных проблем в конкретных "проблемных" областях кода.
  • TRACE: "Серьезно, WTF здесь происходит?!?! Мне нужно регистрировать каждый отдельный оператор, который я выполняю, чтобы найти эту ошибку при повреждении памяти @# [email protected], прежде чем я сойду с ума"

Не установлено в камне, но грубое представление о том, как я думаю об этом.

Ответ 2

Неформально я использую эту иерархию,

  • DEBUG - фактические значения трассировки
  • INFO - Что-то случилось - ничего важного, просто флаг
  • WARN - все работает, но что-то не совсем то, что ожидалось
  • ОШИБКА - что-то случилось, что нужно будет исправить, но мы можем продолжать и выполнять другие (независимые) действия.
  • FATAL - серьезная проблема, которую мы не должны даже выполнять

Я вообще буду выпускать с регистрацией INFO, но только если я знаю, что файлы журналов фактически просматриваются (и размер не является проблемой), в противном случае WARN.

Ответ 3

Подумайте, кто должен использовать каждый уровень. В моем коде я сохраняю DEBUG зарезервированный для вывода разработчика, например. выход, который только помог бы разработчику. VERBOSE используется для обычного пользователя, когда требуется много информации. INFO Я обычно использую обычные события (например, отправку веб-страницы, проверку чего-то важного).

И FAIL и WARN довольно понятны.

Ответ 4

Соглашение в моей команде состоит в том, чтобы использовать debug, если что-то вычисляется в сообщении, тогда как info используется для обычного текста. Таким образом, эффект info покажет вам, что происходит, и debug покажет значения событий, которые происходят.

Ответ 5

Я склонен нацелить INFO на пользователя, чтобы дать им сообщения, которые даже не предупреждают. DEBUG имеет тенденцию использоваться для разработчиков, когда я выводю сообщения, чтобы помочь проследить поток через код (также со значениями переменных).

Мне также нравится еще один уровень DEBUG (DEBUG2?), который дает абсолютные bucketloads отладочной информации, такие как шестнадцатеричные дампы всех буферов и т.д.

Ответ 6

Нет необходимости в уровне DEBUG2. Для чего нужна "ТРЕЙС". TRACE предназначен для абсолютного минимального уровня регистрации, выводящего все возможные фрагменты информации, которые вы, возможно, захотите увидеть.

Чтобы избежать потопа информации, обычно не рекомендуется включать протоколы трассировки на весь проект. Вместо этого используйте "DEBUG", чтобы узнать общую информацию об ошибке и ее месте (отсюда и название), а затем включить TRACE только для этого компонента, если вы все еще не можете понять это.