Мне кажется более полезным думать о серьезности с точки зрения просмотра файла журнала.
Неустранимый / Критический : Общий сбой приложения или системы, который следует немедленно расследовать. Да, разбуди Сисадмина. Так как мы предпочитаем, чтобы наши SysAdmins были предупреждены и хорошо отдохнули, эту серьезность следует использовать очень редко. Если это происходит ежедневно, и это не BFD, значит, оно потеряно. Как правило, неустранимая ошибка возникает только один раз за время существования процесса, поэтому, если файл журнала связан с процессом, это, как правило, последнее сообщение в журнале.
Ошибка : Определенно проблема, которую следует изучить. SysAdmin должен быть уведомлен автоматически, но его не нужно тащить с кровати. Фильтруя журнал для просмотра ошибок и выше, вы получаете обзор частоты ошибок и можете быстро определить первоначальный сбой, который мог привести к каскаду дополнительных ошибок. Отслеживание частоты ошибок по сравнению с использованием приложения может дать полезные показатели качества, такие как MTBF, которые можно использовать для оценки общего качества. Например, этот показатель может помочь в принятии решений о том, нужен ли еще один цикл бета-тестирования перед выпуском.
Предупреждение : Это МОЖЕТ быть проблемой, а может и не быть. Например, ожидаемые переходные условия окружающей среды, такие как кратковременная потеря подключения к сети или базе данных, должны регистрироваться как предупреждения, а не ошибки. Просмотр журнала, отфильтрованного для отображения только предупреждений и ошибок, может дать быстрое представление о ранних подсказках об основной причине последующей ошибки. Предупреждения следует использовать с осторожностью, чтобы они не стали бессмысленными. Например, потеря доступа к сети должна быть предупреждением или даже ошибкой в серверном приложении, но это может быть просто информация в настольном приложении, предназначенном для периодически отключенных пользователей ноутбуков.
Информация : Это важная информация, которая должна регистрироваться при нормальных условиях, таких как успешная инициализация, запуск и остановка служб или успешное завершение значительных транзакций. Просмотр журнала с информацией и выше должен дать краткий обзор основных изменений состояния в процессе, предоставляя контекст верхнего уровня для понимания любых предупреждений или ошибок, которые также происходят. Не иметь слишком много информационных сообщений. Обычно у нас есть <5% информационных сообщений относительно трассировки. </p>
Трассировка : Трассировка является наиболее часто используемой серьезностью и должна обеспечивать контекст для понимания шагов, приводящих к ошибкам и предупреждениям. Правильная плотность сообщений Trace делает программное обеспечение более удобным в обслуживании, но требует некоторого усердия, потому что значение отдельных операторов Trace со временем может изменяться по мере развития программ. Лучший способ добиться этого - заставить команду разработчиков регулярно просматривать журналы как стандартную часть устранения неполадок, о которых сообщают клиенты. Поощряйте команду удалять сообщения трассировки, которые больше не предоставляют полезный контекст, и добавлять сообщения, где это необходимо, чтобы понять контекст последующих сообщений. Например, часто полезно регистрировать пользовательский ввод, такой как изменение отображения или вкладок.
Отладка : Мы считаем, что Отладка <Трассировка. Различие заключается в том, что сообщения отладки компилируются из сборок Release. Тем не менее, мы не рекомендуем использовать сообщения отладки. Разрешение сообщений отладки приводит к добавлению все большего количества сообщений отладки, и ни одно из них никогда не удаляется. Со временем это делает файлы журналов практически бесполезными, потому что слишком сложно фильтровать сигнал от шума. Это приводит к тому, что разработчики не используют журналы, которые продолжают спираль смерти. Напротив, постоянное сокращение сообщений трассировки побуждает разработчиков использовать их, что приводит к добродетельной спирали. Кроме того, это исключает возможность появления ошибок из-за необходимых побочных эффектов в отладочном коде, который не включен в сборку релиза. Да, я знаю, что это не должно происходить в хорошем коде, но лучше, потом извините. </p>