Приоритеты ведения журнала приоритетов - PullRequest
13 голосов
/ 20 сентября 2011

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

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

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

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

Ответы [ 6 ]

10 голосов
/ 20 сентября 2011

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

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

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

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

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

Редактировать: вы уже просматривали Apache Commons Ведение журнала лучших рассказов ?

6 голосов
/ 20 сентября 2011

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

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

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

ПРЕДУПРЕЖДЕНИЕ - не уровень ошибки как таковой, но полезно знать, что система может входить в хитрую территорию, например, бизнес-логика, такая как «количество заказанных продуктов <0», которая предполагает ошибку где-то, но не является системным исключением; Честно говоря, я не использую его настолько, чтобы находить вещи более естественными для INFO или ERROR </p>

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

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

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

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

2 голосов
/ 20 сентября 2011

Мой дубль

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

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

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

  • Уровень ALL имеет наименьший возможный ранг и предназначен для включения всей регистрации.

  • Уровень DEBUG обозначает подробные информационные события, которые наиболее полезны для отладки приложения.

  • Уровень ОШИБКА обозначает события ошибок, которые могут все еще позволить приложению продолжать работу.

  • Уровень FATAL обозначает очень серьезные события ошибок, которые предположительно приведут к отмене приложения.

  • Уровень INFO обозначает информационные сообщения, которые освещают прогресс приложения на крупном уровне.

  • Уровень OFF имеет наивысший возможный ранг и предназначен для отключения регистрации.

  • Уровень TRACE обозначает более мелкие информационные события, чем DEBUG

  • Уровень WARN обозначает потенциально опасные ситуации.

1 голос
/ 27 сентября 2011

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

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

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

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

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

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

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

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

0 голосов
/ 28 сентября 2011

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

  • DEBUG : выключен в работе, поэтому в основном используется разработчиком для регистрации определенных запросов, времени, параметразначения и т. д.

  • INFO : регистрируйте все, чтобы вы знали в ретроспективе все, чтобы объяснить, как были рассчитаны ваши результаты, и чтобы выможет исправлять ошибки

  • ОШИБКА : Все, что требует внимания (разработчиков / операций)

Я не использую WARN , потому что никто никогда не фильтрует все файлы журналов для сообщений WARN.Если это важно, то это ОШИБКА (и кто-то должен позаботиться об этом), если нет, то это ИНФО (и никто не заинтересован в этом, пока не возникнет проблема).То же самое для FATAL.

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

...