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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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