Какие соглашения вы используете для журнальных категорий в log4j или подобных библиотеках? Обычно вы видите имена классов как категории, но используете ли вы другие системы?Соглашения о регистрации
Как насчет уровней бревен? Какие уровни вы используете и в каком случае?
Обновление: как некоторые из вас ответили, нет «правильного» ответа. Я просто ищу, какие разные условности используют люди как возможный источник вдохновения.
У меня есть 3 уровня: ошибки, предупреждения и подробный журнал, рассказывающий, что программа делает за один раз.
Я использую функцию класса + в качестве контекста.
У нас были обширные дебаты об этом на протяжении многих лет, и единственное, на что мы все согласны, заключается в том, что нет идеального ответа!
. Мы остановились на использовании названия категории верхнего уровня, чтобы различать широкие категории: например, «Операция» относится ко всему, что может волноваться пользователю, «Внутренний» относится к вещам, о которых заботится только разработчик, «Аудит» используется для отслеживания интересных событий.
Помимо этого мы пытаемся установить ограничение количество категорий, так как мы не находим никого, когда-либо включающих/выключая их на более подробном уровне. Поэтому вместо имен классов мы пытаемся сгруппировать их в функциональную область, например. Запрос, обновления и т. Д.
Ведение журнала зависит от ваших требований. Если вы создаете журнал, который просто содержит вкладки о том, были ли какие-либо проблемы (например, исключения журналов), вам может потребоваться только имя класса и функции.
Однако, если у вас есть функциональное требование для создания и аудита следа сортировки, то регистрация должна быть взята на совершенно другой уровень детализации.
У нас есть журналы отладки, которые являются методом класса +.
У нас также есть определенные журналы для определенных действий, например, соединения, полученного в сокете. Это то, что я называю «журналами фактов» или «журналами аудита аудита», они регистрируют один тип вещей. Конечно, недавно я просто привязал их к базе данных, потому что факты, которые вы захватываете, могут быть намного сложнее, чем строка текста, они могут включать состояние в определенное время. I.e., вы катите свой собственный механизм записи журнала аудита для каждой требуемой аудита.
При отладке мы установим пакет/класс, который мы отлаживаем в DEBUG в log4j, оставив корневой шпион в ERROR, и у нас будет файл журнала отладки, который, надеюсь, не будет содержать все записи gumpf из других областей приложение.
Но на самом деле не существует «правильного пути» для выполнения этих действий. Комбинация механизмов кажется хорошей, но она зависит от того, что вы хотите регистрировать.
Я согласен с Vaibhav's answer: вы должны знать, почему вы регистрируетесь.
Так только для внутреннего протоколирования, мы следуем за довольно стандартный подход:
Зеркальность (для классического внутреннего лесозаготовки) является основным классом, отвечающим за главный ste ps процесса.