Уровни ведения журнала - Logback - практическое правило для назначения уровней ведения журнала

Я использую logback в моем текущем проекте.

Он предлагает шесть уровней регистрации: TRACE DEBUG INFO WARN ERROR OFF

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

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

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

• ошибка : система находится в бедственном положении, клиенты, вероятно, затронуты (или скоро будут), и исправление, вероятно, требует вмешательства человека. Здесь действует «правило 2 утра» - если вы на связи, хотите ли вы проснуться в 2 часа ночи, если это условие произойдет? Если да, то зарегистрируйте его как «ошибка».

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

• информация : вещи, которые мы хотим видеть в большом объеме на случай, если нам понадобится провести судебный анализ проблемы. События жизненного цикла системы (запуск, остановка системы) идут здесь. События «жизненного цикла» сеанса (вход, выход и т. Д.) Идут здесь. Также следует учитывать важные граничные события (например, вызовы базы данных, удаленные вызовы API). Сюда могут входить типичные бизнес-исключения (например, сбой входа в систему из-за неверных учетных данных). Любое другое событие, которое, по вашему мнению, вам нужно увидеть в производстве в большом объеме, идет сюда.

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

• trace : мы используем это не часто, но это было бы для очень подробных и потенциально больших журналов, которые обычно не нужно включать даже во время обычной разработки. Примеры включают в себя сброс полной иерархии объектов, запись некоторого состояния во время каждой итерации большого цикла и т. Д.

Более важным, чем выбор правильных уровней журналов, является обеспечение того, чтобы журналы были значимыми и имели необходимый контекст. Например, вы почти всегда захотите включить идентификатор потока в журналы, чтобы при необходимости вы могли следить за одним потоком. Вы также можете использовать механизм для привязки бизнес-информации (например, идентификатора пользователя) к потоку, чтобы она также регистрировалась. В своем сообщении журнала вы захотите включить достаточно информации, чтобы сообщение могло быть активным. Журнал типа «FileNotFound исключение обнаружен» не очень полезен. Лучшее сообщение: «Возникла исключительная ситуация FileNotFound при попытке открыть файл конфигурации: /usr/local/app/somefile.txt. UserId = 12344».

Существует также несколько хороших руководств по ведению журналов ... например, вот отредактированный фрагмент из JCL (Jakarta Commons Logging) :

• ошибка - другие ошибки во время выполнения или непредвиденные условия. Ожидайте, что они будут немедленно видны на консоли состояния.
• warn - Использование устаревших API, плохое использование API, «почти» ошибки, другие ситуации времени выполнения, которые нежелательны или неожиданны, но не обязательно «неправильны». Ожидайте, что они будут немедленно видны на консоли состояния.
• информация - Интересные события времени выполнения (запуск / выключение). Ожидайте, что они будут немедленно видны на консоли, поэтому будьте консервативны и соблюдайте минимум.
• debug - подробная информация о потоке в системе. Ожидайте, что они будут записаны только в журналы.
• трассировка - более подробная информация. Ожидайте, что они будут записаны только в журналы.

Я думаю, что мой подход больше основан на разработке, чем на эксплуатации:

• ошибка означает, что выполнение некоторой задачи не может быть завершено; электронное письмо не может быть отправлено, страница не может быть отображена, некоторые данные не могут быть сохранены в базе данных, что-то в этом роде. Что-то окончательно пошло не так.
• Предупреждение означает, что произошло нечто неожиданное, но выполнение может продолжаться, возможно, в ухудшенном режиме; файл конфигурации отсутствовал, но использовались значения по умолчанию, цена была рассчитана как отрицательная, поэтому она была ограничена до нуля и т. д. Что-то не так, но все еще не работает должным образом - предупреждения часто являются признаком того, что они будут ошибка очень скоро.
• Информация означает, что произошло нечто нормальное, но значительное; система запустилась, система остановилась, запустилось ежедневное задание обновления инвентаря и т. д. Их не должно быть непрерывным потоком, в противном случае слишком много нужно прочитать.
• Отладка означает, что произошло что-то нормальное и незначительное; на сайт зашел новый пользователь, была отображена страница, принят заказ, обновлена ​​цена. Этот материал исключен из информации, потому что его было бы слишком много.
• Trace - это то, что я никогда не использовал.

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

Например :

• "Будет ли строка кода регистрации, которая регистрируется в WARN, действительно регистрироваться в моем развертывании, настроенном с ОШИБКОЙ?" Таблица говорит, НЕТ.
• "Будет ли строка кода регистрации, которая регистрируется в WARN, действительно регистрироваться в моем развертывании, настроенном с помощью DEBUG?" Таблица говорит, ДА.

из документации на вход в систему :

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

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

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

• ОШИБКА - у этого компонента произошел сбой, и причина считается внутренней (любое внутреннее, необработанное исключение, сбой инкапсулированной зависимости ... например, база данных, пример REST, если он получил ошибку 4xx от зависимости). Вытащи меня (сопровождающего этого компонента) из постели.

• ПРЕДУПРЕЖДЕНИЕ. Считается, что этот компонент вызван ошибкой зависимого компонента (пример REST будет состоянием 5xx из зависимости). Уберите тех, кто поддерживает компонент ТО, с постели.

• ИНФОРМАЦИЯ - Все остальное, что мы хотим донести до оператора. Если вы решите регистрировать счастливые пути, тогда я рекомендую ограничить до 1 сообщения журнала за значительную операцию (например, за входящий HTTP-запрос).

Для всех сообщений журнала обязательно регистрируйте полезный контекст (и отдавайте предпочтение тому, чтобы сделать сообщения удобочитаемыми / полезными, а не имеющими множество "кодов ошибок")

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

Хороший способ визуализации вышеуказанных уровней ведения журнала - представить набор экранов мониторинга для каждого компонента. Когда все работает хорошо, они зеленые, если компонент регистрирует ПРЕДУПРЕЖДЕНИЕ, тогда он станет оранжевым (янтарным), если что-либо регистрирует ОШИБКУ, то он станет красным.

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

Не отличается для других ответов, мои рамки имеют почти те же уровни:

1. Ошибка: критические логические ошибки в приложении, такие как тайм-аут соединения с базой данных. Вещи, которые требуют исправления в ближайшем будущем
2. Предупреждаю: не волнующие вопросы, но вещи, на которые стоит обратить внимание. Как и запрошенная страница не найдена
3. Информация: используется в первой строке функций / методов, чтобы показать вызванную процедуру или выполненный шаг, например, выполненный запрос вставки
4. log: логическая информация, как результат оператора if
5. отладка: переменное содержимое релевантно для постоянного просмотра