Передовые методы приоритетов ведения журналов Commons

Это может быть чисто субъективный вопрос (если ни одна организация не пыталась стандартизировать это), но моя команда борется с этим больше, чем вы думаете.

Мы используем ведение журнала Apache Commons как наш интерфейс ведения журнала, и часто использование приоритета не соответствует нашей команде разработчиков. Например, некоторые разработчики регистрируют любое застигнутое исключение для фатального (log.fatal(message)), даже если поток способен обрабатывать ошибку, тогда как другие регистрируются только до фатальной, когда что-то заставляет программу обязательно прекращать выполнение по любой причине.

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

Моя цель состояла бы в том, чтобы отправить простую рекомендацию для каждого приоритета всей моей команде, чтобы мы могли более эффективно обрабатывать нашу громоздкую регистрацию приложений согласованным образом.

Ответ 1

Здесь мы используем (и я бы сказал, что многие другие):

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

В некоторых случаях мы начинаем с протоколирования сообщений как ОШИБКА, чтобы получить уведомление, когда произойдет что-то, что обычно не происходит. Позже, если мы решим, что источник этой ошибки не может быть удален, мы обрабатываем его и меняем уровень журнала на WARN.

Обратите внимание, что наши тестовые и производственные системы настроены для отправки электронной почты для FATAL и ERROR. Таким образом, нам не нужно проверять файлы журнала для них вручную, но только нужно проверить один почтовый ящик.

Надеюсь, что это поможет.

Изменить: вы уже посмотрели Apache Commons Logging лучшие оценки?

Ответ 2

Я всегда использовал это как руководство; Я использую Log4j больше, чем Commons Logging, но это может быть полезно:

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

INFO - минимальный уровень для производства/отгрузки; записи данных, которые могут быть полезны в судебных расследованиях и для подтверждения успешных результатов ( "хранится 999 элементов в БД ОК" ); вся информация здесь должна быть такой, чтобы вы были в порядке с конечными пользователями/клиентами, видящими ее и отправляя вам, если нужно (без секретов, без профанации!)

WARN - не является уровнем ошибки как таковой, но полезно знать, что система может входить в изворотливую территорию, например. бизнес-логику, например "количество упорядоченных продуктов < 0", что указывает на ошибку где-то, но не является системным исключением; Я склонен не использовать его так, чтобы быть честным, поиск вещей, как правило, более естественным образом подходит для INFO или ERROR

ОШИБКА - используйте это для исключений (если нет веских оснований для уменьшения до WARN или INFO); log full stacktraces вместе с важными значениями переменных, без которых невозможно установить диагноз; использовать только для приложений/системных ошибок, не плохой бизнес-логики

FATAL - используйте только эту ошибку с такой высокой степенью серьезности, что она буквально запрещает запуск/продолжение приложения.

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

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

Ответ 3

Мой прием

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

Ответ 4

Это то, что моя компания рекомендует:

TRACE. Сообщения, вероятно, полезны только во время цикла разработки и, возможно, слишком часто используются для подходящего использования в производстве. Например, если я регистрирую промежуточные значения во внутреннем цикле, Id использует TRACE.

DEBUG. Сообщения, используемые для регистрации различных шагов при нормальной работе сервера. Как правило, они будут нацелены на разработчиков, а не на персонал.

INFO. Сообщения положительного или нейтрального характера, которые мы ожидаем, чтобы они вошли в производственную среду. Должен иметь смысл для персонала операций.

WARN. Сообщения, указывающие на состояние, возможно, угрожающее способности сервера реагировать на запросы точным и своевременным образом.

ОШИБКА. Сообщения, указывающие на непредвиденное поведение или состояние.

FATAL. Сообщения, указывающие на непредвиденное поведение или условие, которое оставляет невозможным или опасным продолжение процесса приложения.

Мы ожидаем, что журналы в производстве будут установлены в INFO, и мы ожидаем, что их прочитают люди, отличные от разработчиков. Стиль сообщений журнала - это еще один разговор...

Ответ 5

Если вы ищете простую рекомендацию, которая поддерживается отраслью, почему бы просто не взглянуть на простую реализацию/документацию в отрасли?

Мы используем API logback/log4j как руководство по уровню ведения журнала = > , которое делает его простым/документированным/поддерживаемым промышленность:

Уровень ВСЕ имеет самый низкий ранг и предназначен для включения всех протоколов.
Уровень DEBUG обозначает мелкомасштабные информационные события, которые наиболее полезны для отладки приложения.
Уровень ОШИБКА обозначает события ошибки, которые могут позволить продолжить работу приложения.
Уровень FATAL обозначает очень серьезные ошибки, которые предположительно приведут к прерыванию приложения.
Уровень INFO обозначает информационные сообщения, которые выделяют прогресс приложения на крупнозернистом уровне.
Уровень ВЫКЛ имеет наивысший возможный ранг и предназначен для отключения регистрации.
Уровень TRACE обозначает более мелкие информационные события, чем DEBUG
Уровень WARN обозначает потенциально опасные ситуации.

Ответ 6

Я использую более простой подход:

DEBUG. Отключено в производстве, поэтому в основном используется разработчиком для регистрации определенных запросов, таймингов, значений параметров и т.д.
INFO: зарегистрируйте все, чтобы вы все знали, чтобы объяснить, как были вычислены ваши результаты, и чтобы вы могли исправлять ошибки
ОШИБКА: все, что нужно кому-то (разработчик/операции) внимание

Я не использую WARN, потому что никто не фильтрует все файлы журналов для сообщений WARN. Если это важно, то это ERROR (и кому-то это нужно), если нет, это INFO (и никто не заинтересован в нем до тех пор, пока не возникнет проблема). То же самое для FATAL.

Я также не использую TRACE. Все, что мне нужно знать во время разработки, - DEBUG.