Уровни ведения журнала - Logback - правило большого пальца, чтобы назначить уровни журналов

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

• WARN. У этого компонента произошел сбой, который, как полагают, вызван зависимым компонентом (пример REST будет состоять из статуса 5xx от зависимости). Получите сопровождение компонента THAT с постели.

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

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

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

Хорошим способом визуализации вышеупомянутых уровней регистрации является представление набора экранов мониторинга для каждого компонента. Когда все работает хорошо, они зеленые, если компонент регистрирует WARNING, тогда он будет оранжевым (янтарным), если что-то записывает ERROR, тогда оно будет красным.

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

Ответ 4

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

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

Ответ 5

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

Примеры:

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

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

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

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