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

Есть разные способы записи сообщений в порядке фатальности:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

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

Какую эвристику использовать?

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

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

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

• да -> ошибка
• нет -> предупредить

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

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

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

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

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

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

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

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

Apache log4j: §1 , §2

1. FATAL:

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

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

2. ERROR:

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

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

3. WARN:

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

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

4. INFO:

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

   [ v2.0 : ..] событие в информационных целях.

5. DEBUG:

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

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

6. TRACE:

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

   [ v2.0 : ..] детальное отладочное сообщение, обычно фиксирующее поток через приложение.

Apache Httpd (как обычно) любит идти на перебор: §

1. Emerg :

   Чрезвычайные ситуации - система не работает.

2. оповещение :

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

3. крит :

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

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

4. ошибка :

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

   • « Преждевременный конец заголовков скриптов »

5. предупредить :

   Условия предупреждения. [близко к ошибке, но не к ошибке]

6. уведомление :

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

   • " httpd: пойман SIGBUS, пытается сбросить ядро ​​в ... "

7. информация :

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

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

8. отладка :

   Сообщения отладки уровня [, то есть сообщения , фиксируемые для де-подслушивания )].

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

9. trace1 → trace6 :

   Сообщения трассировки [т.е. сообщения, зарегистрированные для отслеживания ].

   • " прокси: FTP: управляющее соединение установлено "
   • « proxy: CONNECT: отправка запроса CONNECT на удаленный прокси »
   • " openssl: рукопожатие: начало "
   • « читать из буферизованной бригады SSL, режим 0, 17 байт »
   • " Поиск по карте НЕ УКАЗАН:map=rewritemap key=keyname "
   • " Сбой поиска в кэше, форсированный поиск новой карты "

10. 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: §

1. фатальный :

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

2. ошибка :

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

3. предупредить :

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

4. информация :

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

5. отладка :

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

6. трассировка :

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

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

Границы включают в себя:

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

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

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

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

(Подробнее об этом см. В руководстве по ведению общего журнала .)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из RFC 5424, Протокол системного журнала (IETF) - Страница 10:

Каждое приоритетное сообщение также имеет десятичный индикатор уровня серьезности. Они описаны в следующей таблице вместе с их числовыми значениями. Значения серьезности ДОЛЖНЫ быть в диапазоне от 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

          Table 2. Syslog Message Severities

G'day,

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

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

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

НТН

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

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

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

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

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

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

Вот некоторые примеры:

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

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

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

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

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

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

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

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

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

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

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

1. ОШИБКА - означает, что что-то серьезно не так, и этот конкретный поток / процесс / последовательность не может продолжаться. Требуется вмешательство пользователя / администратора
2. ВНИМАНИЕ - что-то не так, но процесс может продолжаться, как и раньше (например, одно задание в наборе из 100 завершилось неудачно, но остальное можно обработать)

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

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

Что произойдет, если вы выполняете захват на уровне «Предупреждение» и хотите получить некоторую информацию об отладке, связанную с предупреждением, но не смогли восстановить предупреждение?

Захватите все и отфильтруйте позже!

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

Захватите все и отфильтруйте позже !!

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

Мои два цента о FATALи TRACEуровни журнала ошибок.

ERROR когда происходит какой-то сбой (исключение).

FATAL на самом деле DOUBLE FAULT: когда происходит исключение во время обработки исключения.

Это легко понять для веб-службы.

1. Просьба прийти. Событие зарегистрировано какINFO
2. Система обнаруживает недостаток дискового пространства. Событие зарегистрировано какWARN
3. Для обработки запроса вызывается некоторая функция. При обработке деление на ноль происходит. Событие зарегистрировано какERROR
4. Обработчик исключений веб-службы вызывается для обработки деления на ноль. Веб-сервис / фреймворк собирается отправлять электронную почту, но не может, потому что почтовый сервис сейчас отключен. Это второе исключение не может быть обработано нормально, потому что обработчик исключений веб-службы не может обработать исключение.
5. Вызывается другой обработчик исключений. Событие зарегистрировано какFATAL

TRACEкогда мы можем отследить функцию входа / выхода. Это не относится к ведению журнала, потому что это сообщение может быть сгенерировано каким-либо отладчиком, а ваш код вообще не обращался к нему log. Таким образом, сообщения, которые не из вашего приложения, помечены как TRACEуровень. Например, вы запустите приложение с помощьюstrace

Так обычно в вашей программе вы делаете DEBUG, INFOи WARNведение журнала. И только если вы пишете какой-то веб-сервис / фреймворк, вы будете использовать FATAL. И когда вы отлаживаете приложение, вы получаете TRACEлоги от этого типа программного обеспечения.

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

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