Как создать имена уровня журнала. Отразить частоту использования?

Question

Я собираюсь построить отличную систему. Думая об именовании уровня журнала Удиви меня.

1. Могу ли я выбрать имена, чтобы администратор и разработчики знали, какие использовать. Без использования документации?

Было бы хорошо, если бы уровень журнала также отражал как часто они будут отображаться в журналах.

Например:

• INIT / SHUTDOWN - (появляется один раз)
• FUNC_CALL - (появляются часто, например, в циклах)
• TRACE - (несколько раз в функциях)

Теперь системный администратор никогда не включит TRACE, входящий в систему. Он может безопасно включить INIT / SHUTDOWN. И FUNC_CALL, если в системе низкий трафик.

Что не так с этим дизайном?

Какие имена вы бы использовали, чтобы отразить частоту?

(я знаю о WARN, INFO и ERROR.)

Answer 1

Я бы пошел с более самоописывающимися именами, например:

• EVERYTHING_IS_BROKEN_IMMEDIATE_ATTENTION_REQUIRED
• RARE_IMPORTANT_EVENT (включая init / shutdown)
• DETAILED_EXECUTION_TRACE
• TONS_OF_DEBUGGING_INFORMATION

Может быть, не совсем эти, но вы поняли - убедитесь, что совершенно невозможно запутаться в том, что означает каждый уровень журнала. (Я также использовал термин «трассировка» в более консервативном смысле - список вызовов функций на самом деле является трассировкой, поэтому FUNC_CALL и TRACE звучат для меня как синонимы)

Также не делайте уровней журнала, которые никто не должен отключать. Лично я всегда считал уровни ERROR / WARNING / INFO по умолчанию глупыми, потому что они вводят в заблуждение (является ли запрос на несуществующий элемент ошибкой?)

Также было бы хорошо, если бы никто не смог (случайно) отключить уровни EVERYTHING_IS_BROKEN_IMMEDIATE_ATTENTION_REQUIRED и RARE_IMPORTANT_EVENT.

Не бойтесь использовать длинные имена, IDE все равно будут автоматически заполнять их. Лучше иметь более длинные имена, чем испорченные логи.

Answer 2

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

Поэтому я всегда рекомендую различать журналы по срочности необходимого ответа. Имена уровня логина Андрея могли бы быть немного ненормативной, но концепция была правильной. Уровни журнала должны отражать следующее:

• (самая высокая) система сломана - требуется немедленное вмешательство
• Возможная поломка или возникновение проблемы - необходимо расследование с возможным вмешательством
• Статус / информационная отчетность - рутинное сердцебиение или сводная статистика

Этот последний служит двум целям: одному явному и одному тонкому. Очевидной целью является регистрация полезной информации о состоянии и производительности приложения. Во-вторых, регулярный вывод в журнал позволяет оператору узнать, что приложение все еще работает нормально. (То есть, если я вижу файл журнала без новых записей за последние 3 часа, я могу предположить, что он уже мертв.)

Answer 3

В существующих каркасах журналирования, таких как log4j, уровень серьезности и местоположение в программе являются двумя ортогональными понятиями.

Log4j определяет следующие уровни: TRACE, DEBUG, INFO, WARN, ERROR и FATAL, но можно также фильтровать выходные данные в соответствии с классом, в котором ведется журнал.

Answer 4

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

Затем, похоже, что FUNC_CALL и TRACE являются хорошими именами для этапов подготовки производства, когда вы хотите увидеть, по причинам теста, что именно выполняется.

Но в производстве должны оставаться только журналы, связанные с функционалом (обычно журналы WARNING и SEVERE о функциональных возможностях), и даже они могут быть опасными (особенно ПРЕДУПРЕЖДЕНИЕ в цикле для нескольких тысяч экземпляров).

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