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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Например :

• "Будет ли на самом деле записана строка кода регистрации, которая регистрируется в WARN, в моем развертывании, настроенном с ошибкой?"В таблице написано: NO.
• "Будет ли на самом деле записана строка кода регистрации, которая регистрируется в WARN, в моем развертывании, настроенном с помощью DEBUG?"В таблице написано: ДА.

из документация по журналу :

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

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

Answer 4

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

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

• WARN - Сбой этого компонента, как считается, вызван зависимым компонентом (пример REST будет состоянием 5xx из зависимости). Уберите тех, кто поддерживает компонент ТО, с кровати.

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

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

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

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

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

Answer 5

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

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