Как определить, какой уровень журнала использовать? [закрытый]
уровни журнала предупреждают, ошибка и фатальные довольно ясны. Но когда что-то отлаживается, и когда информация?
Я видел некоторые проекты, которые раздражающе многословны на информационном уровне, но я также видел код, который слишком сильно поддерживает уровень отладки. В обоих случаях полезная информация скрыта в шуме.
каковы критерии для определения уровней входа?
6 ответов:
Я не думаю, что есть какие-либо жесткие и быстрые правила; используя уровни типа log4j, мои "эмпирические правила" - это что-то вроде:
- фатальная: приложение (или, по крайней мере, поток) вот-вот умрет ужасно. Вот где информация объясняет почему что происходит идет.
- : что-то, что приложение делает, что он не должен. Это не ошибка пользователя ('неверный запрос'); это сбой утверждения, сеть проблема и т. д. и т. п., вероятно, тот, который собирается прервать текущую операцию
- предупредить: что-то, что касается, но не вызывает прерывания операции; # соединения в пуле БД становятся низкими, необычный, но ожидаемый тайм-аут в операции и т. д. Я часто думаю о "предупреждении" как о чем-то полезном в совокупности; например, grep, group и count их, чтобы получить представление о том, что влияет на здоровье системы
- INFO: нормальное ведение журнала это часть нормальной работы приложения; диагностический материал, чтобы вы могли вернуться и сказать :" как часто это происходило на широком уровне?", или " как данные пользователя попали в это состояние?-
- DEBUG: выключен по умолчанию, может быть включен для отладки конкретных неожиданных проблем. Здесь вы можете записать подробную информацию о ключевых параметрах метода или другую информацию, которая полезна для поиска вероятных проблем в определенных "проблемных" областях код.
- TRACE: "серьезно, WTF здесь происходит?!?! Мне нужно регистрировать каждый оператор, который я выполняю, чтобы найти эту ошибку повреждения памяти @#$@ing, прежде чем я сойду с ума"
не установлены в камне, но примерное представление о том, как я думаю об этом.
неофициально я использую такую иерархию,
- DEBUG-фактические значения трассировки
- информация-что - то только что произошло-ничего важного, просто флаг
- предупреждаю - все работает, но что-то не совсем то, что ожидалось
- ошибка-что-то произошло, что нужно будет исправить, но мы можем продолжать и делать другие (независимые) действия
- FATAL-достаточно серьезная проблема, которую мы даже не должны продолжать
Я обычно выпускаю с регистрируемой информацией, но только если я знаю, что файлы журналов действительно просматриваются (и размер не является проблемой), в противном случае это предупреждает.
думать о том, кто должен использовать каждый уровень. В моем коде я держу DEBUG зарезервировано для вывода разработчика, например, вывода, который только поможет разработчику. подробное используется для обычного пользователя, когда требуется много информации. INFO Я обычно показываю основные события (например, отправку веб-страницы, проверку чего-то важного).
и FAIL и предупредить довольно понятны.
конвенция в моей команде-это использовать
debugЕсли что-то вычисляется в сообщении, тоinfoиспользуется для обычного текста. Так что в действительностиinfoпокажет вам, что происходит, иdebugпокажет значения вещей, которые происходят.
Я, как правило, целевой информации к пользователю, чтобы дать им сообщения, которые даже не предупреждения. DEBUG, как правило, используется разработчиком, где я выводил сообщения, чтобы помочь отслеживать поток через код (со значениями переменных).
Мне также нравится другой уровень отладки (DEBUG2?) который дает абсолютные бакеты отладочной информации, такие как шестнадцатеричные дампы всех буферов и так далее.
нет необходимости в уровне DEBUG2. Вот для чего нужен "след". Трассировка предназначена для абсолютного самого низкого уровня ведения журнала, выводящего все возможные сведения, которые вы можете захотеть увидеть.
чтобы избежать потока информации, обычно не рекомендуется включать ведение журнала на уровне трассировки во всем проекте. Вместо этого используйте "DEBUG", чтобы узнать общую информацию об ошибке и где она возникает (отсюда и название), а затем включить трассировку только для этого компонент, если вы все еще не можете понять это.
Comments