Подтвердить что ты не робот

Когда использовать разные уровни журналов

Существуют разные способы протоколирования сообщений в порядке убывания:

  • FATAL

  • ERROR

  • WARN

  • INFO

  • DEBUG

  • TRACE

Как мне решить, когда использовать?

Какая хорошая эвристика для использования?

4b9b3361

ОТВЕТЫ

Ответ 1

Я обычно подписываюсь на следующее соглашение:

  • Трассировка. Только тогда, когда я буду "отслеживать" код и попытаться найти одну часть для функции.
  • Отладка. Информация, которая диагностически полезна людям больше, чем просто разработчики (ИТ, системные администраторы и т.д.).
  • Информация. Обычно полезная информация для журнала (запуск/останов службы, предположения о конфигурации и т.д.). Info Я хочу всегда иметь доступный, но обычно не заботясь при нормальных обстоятельствах. Это мой готовый конфигурационный уровень.
  • Предупреждать - все, что может потенциально вызвать странности приложений, но для которых я автоматически восстанавливаю. (Например, переход от основного к резервному серверу, повторная операция, отсутствие вторичных данных и т.д.).
  • Ошибка. Любая ошибка, которая является фатальной для операции , но не службой или приложением (не может открыть необходимый файл, отсутствующие данные и т.д.). Эти ошибки заставят вмешательство пользователя (администратора или прямого пользователя). Обычно они зарезервированы (в моих приложениях) для неправильных строк подключения, отсутствующих служб и т.д.
  • Fatal. Любая ошибка, которая вынуждает отключить службу или приложение для предотвращения потери данных (или дальнейшей потери данных). Я резервирую их только для самых отвратительных ошибок и ситуаций, когда гарантируется повреждение или потеря данных.

Ответ 2

Хотите, чтобы сообщение вышло из системного администратора из постели посреди ночи?

  • да → ошибка
  • no → warn

Ответ 3

Я считаю более полезным подумать о серьезности с точки зрения просмотра файла журнала.

Fatal/Critical. Общее нарушение приложения или системы, которое должно быть немедленно исследовано. Да, просните SysAdmin. Поскольку мы предпочитаем наше оповещение SysAdmins и хорошо отдохнувшее, эту серьезность следует использовать очень редко. Если это происходит ежедневно, и это не BFD, это потеряло смысл. Как правило, фатальная ошибка возникает только один раз в течение жизненного цикла процесса, поэтому, если файл журнала привязан к процессу, это обычно последнее сообщение в журнале.

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

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

Информация. Это важная информация, которая должна регистрироваться в обычных условиях, таких как успешная инициализация, запуск и остановка служб или успешное завершение значительных транзакций. Просмотр журнала, отображающего информацию и выше, должен дать краткий обзор основных изменений состояния процесса, обеспечивающих контекст верхнего уровня для понимания любых предупреждений или ошибок, которые также происходят. Не слишком много сообщений Info. Обычно у нас есть < 5% Информационные сообщения относительно трассировки.

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

Отладка. Мы рассматриваем Debug < След. Различие заключается в том, что сообщения Debug скомпилированы из версий Release. Тем не менее, мы препятствуем использованию сообщений Debug. Разрешение сообщений отладки приводит к тому, что все больше и больше добавляются отладочные сообщения и никогда не удаляются. Со временем это делает файлы журналов почти бесполезными, потому что слишком сложно фильтровать сигнал от шума. Это заставляет разработчиков не использовать журналы, которые продолжают смертельную спираль. Напротив, постоянно обрезание сообщений Trace побуждает разработчиков использовать их, что приводит к добродетельной спирали. Кроме того, это исключает возможность появления ошибок из-за необходимых побочных эффектов в коде отладки, который не включен в сборку релиза. Да, я знаю, что это не должно происходить в хорошем коде, но лучше безопасно, чем жаль.

Ответ 4

Вот список того, что есть у "регистраторов".

Apache log4j: & sect; 1, & sect; 2

  • FATAL:

    [v1.2:..] очень серьезные события ошибки, которые предположительно приведут приложение к прерванию.

    [v2.0:..] серьезная ошибка, которая предотвратит продолжение приложения.

  • ERROR:

    [v1.2:..] события ошибки, которые все еще могут позволить приложению продолжить работу.

    [v2.0:..] ошибка в приложении, возможно, восстанавливается.

  • WARN:

    [v1.2:..] потенциально опасные ситуации.

    [v2.0:..] событие, которое возможно [sic] приведет к ошибке.

  • INFO:

    [v1.2:..] информационные сообщения, которые выделяют прогресс приложения на крупнозернистом уровне.

    [v2.0:..] для информационных целей.

  • DEBUG:

    [v1.2:..] мелкомасштабные информационные события, которые наиболее полезны для отладки приложения.

    [v2.0:..] общее отладочное событие.

  • TRACE:

    [v1.2:..] более мелкие информационные события, чем DEBUG.

    [v2.0:..] мелкозернистая отладочная информация, обычно захватывающая поток через приложение.

Apache Httpd (как обычно) любит перебирать: & sect;

  • АВАРИЙНО

    Чрезвычайные ситуации – система непригодна.

  • оповещения

    Действие должно быть предпринято немедленно [но система все еще доступна].

  • крит:

    Критические условия [но действие не нужно предпринимать немедленно].

    • ": не удалось получить сокет, выходящий из дочернего элемента

  • Ошибка

    Условия ошибки [но не критические].

    • "Преждевременный конец заголовков script"

  • предупредит

    Условия предупреждения. [close to error, not not error]

  • извещение

    Нормальное, но значительное [примечательное] условие.

    • "httpd: caught SIGBUS, пытаясь сбрасывать ядро ​​в..."

  • Информация

    Информационный [и незаметный].

    • [ "Сервер работает в течение часа".]

  • отладки

    Сообщения уровня отладки [, т.е. сообщения, зарегистрированные в целях деобуки).

    • "Открытие файла конфигурации..."

  • trace1 → trace6

    Отслеживать сообщения [, т.е. сообщения, записанные для отслеживания].

    • "proxy: FTP: завершение подключения к управлению"
    • "proxy: CONNECT: отправка запроса CONNECT удаленному прокси"
    • "openssl: Рукопожатие: начало"
    • "читать из буферизованной SSL-бригады, режим 0, 17 байт"
    • "поиск карты FAILED: map=rewritemap key=keyname"
    • "поиск кэша FAILED, заставляя новый поиск карты"

  • trace7 → trace8

    Отслеживание сообщений, сбрасывание больших объемов данных

    • "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • "| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: & sect;

  • фатальным

    Тяжелые ошибки, которые вызывают преждевременное прекращение. Ожидайте их немедленного отображения на консоли состояния.

  • Ошибка

    Другие ошибки времени выполнения или неожиданные условия. Ожидайте их немедленного отображения на консоли состояния.

  • предупредит

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

  • Информация

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

  • отладки

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

  • след:

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

"Лучшая практика" для использования в компаниях Apache позволяет различать отлаживать и информацию в зависимости от того, какие границы они пересекают.

Границы включают:

  • Внешние границы - ожидаемые исключения.

  • Внешние границы - Неожиданные исключения.

  • Внутренние границы.

  • Значительные внутренние границы.

(Подробнее см. руководство для ведения общедоступных видео.)

Ответ 5

Если вы можете оправиться от проблемы, тогда это предупреждение. Если это предотвращает продолжение выполнения, то это ошибка.

Ответ 6

Я бы рекомендовал принять уровни серьезности системного журнала: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Смотрите http://en.wikipedia.org/wiki/Syslog#Severity_levels

Они должны обеспечивать достаточные уровни детализации для большинства случаев использования и распознаются существующими анализаторами журналов. Хотя у вас, конечно, есть свобода реализации только подмножества, например, DEBUG, ERROR, EMERGENCY в зависимости от требований вашего приложения.

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

Ответ 7

Предупреждения вы можете восстановить. Ошибки вы не можете. Это моя эвристика, у других могут быть другие идеи.

Например, допустим, вы вводите/импортируете имя "Angela Müller" в свое приложение (обратите внимание на умножение над u). Ваш код/​​база данных может быть только на английском языке (хотя, вероятно, не должно быть в наши дни и в таком возрасте) и поэтому может предупредить, что все "необычные" символы были преобразованы в обычные английские символы.

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

Ответ 8

Доступны следующие уровни. Но вы также можете определить пользовательские уровни.

ALL : Все уровни, включая пользовательские уровни.

Trace : Только разработка, может использоваться для выполнение программы.

Debug : Разработка только для целей отладки.

Info : Производя произвольную обработку (редко написанную информацию), я использую ее для печати, когда инициализирована конфигурация, начинается и заканчивается длительное задание импорта.

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

Error : Производство, ошибка/исключение приложения, но приложение может продолжаться. Часть приложения, вероятно, не работает.

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

Off : Не записывать вообще.

Ответ 9

Как говорили другие, ошибки - проблемы; предупреждения являются потенциальными проблемами.

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

Но да, это сводится к аспектам излечимости и актуальности. Если вы можете восстановиться, это, вероятно, предупреждение; если он вызывает что-то на самом деле, это ошибка.

Ответ 10

Я думаю, что уровни SYSLOG NOTICE и ALERT/EMERGENCY в значительной степени являются излишними для ведения журнала на уровне приложений, в то время как CRITICAL/ALERT/EMERGENCY могут быть полезными уровнями оповещения для оператора, который может инициировать различные действия и уведомления, для приложения admin all так же, как FATAL. И я просто не могу в достаточной мере различать то, что ему дают уведомление или какую-то информацию. Если информация не примечательна, это не настоящая информация:)

Мне нравится интерпретация Jay Cincotta наилучшим образом - отслеживание выполнения кода - это что-то очень полезное в технической поддержке, и следует поощрять добавление операторов трассировки в код, особенно в сочетании с механизмом динамической фильтрации для протоколирования сообщений трассировки из определенного приложения компоненты. Однако уровень DEBUG для меня указывает на то, что мы все еще находимся в процессе выяснения того, что происходит. Я вижу вывод уровня DEBUG как вариант только для разработки, а не как что-то, что должно появляться в журнале производства.

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

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

Ответ 11

Ошибка - это что-то не так, просто неправильно, никоим образом не обходимо, оно должно быть исправлено.

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

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

Однако такие вещи, как "выполнение sql занимает слишком много времени", могут быть предупреждением, в то время как "SQL-блокировки выполнения" являются ошибкой, поэтому, возможно, в некоторых случаях.

Ответ 12

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

Ответ 13

Я полностью согласен с другими и считаю, что GrayWizardx сказал это лучше всего.

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

Теперь вы можете выяснить, что может быть смертельным? Вы знаете, что значит роковая, не так ли? Итак, какие элементы в вашем списке смертельны.

Хорошо, что с фатальной проблемой справился, теперь давайте посмотрим на ошибки... промыть и повторить.

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

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

Вот несколько примеров:

Фатальный - не может выделить память, базу данных и т.д. - не может продолжаться.

Ошибка - нет ответа на сообщение, транзакция прервана, невозможно сохранить файл и т.д.

Предупреждение - распределение ресурсов достигает X% (скажем, 80%) - это признак того, что вы можете изменить размер своего.

Информация - пользователь вошел/вышел, новая транзакция, файл создан, новое поле d/b или поле удалено.

Отладка - дамп внутренней структуры данных, уровень Anything Trace с именем файла & номер строки.
Trace - действие выполнено/не выполнено, d/b обновлено.

Ответ 14

От Ietf - Страница 10

Each message Priority also has a decimal Severity level indicator.

Они описаны в следующей таблице вместе с их численными  значения. Значения серьезности ДОЛЖНЫ находиться в диапазоне от 0 до 7 включительно.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

Ответ 15

G'day,

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

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

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

НТН

Ответ 16

Я создал системы до этого, используя следующее:

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

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

Ответ 17

Btw, я большой поклонник захвата всего и фильтрации информации позже.

Что произойдет, если вы будете захватывать на уровне Warning и хотите, чтобы какая-то информация Debug была связана с предупреждением, но не удалось воссоздать предупреждение?

Захват всего и фильтрация позже!

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

Захват всего и фильтрация позже!

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

Ответ 18

Я предлагаю использовать только три уровня

  1. Неустранимый - Который сломал бы приложение.
  2. Инфо - Инфо
  3. Отладка - Менее важная информация