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

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

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

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

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

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

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

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

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

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

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

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

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

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. # P16 #

   # P17 #

2. # P18 #

   # P19 #

3. крит:

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

   • "socket: Failed to get a socket, exiting child"

4. ошибка:

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

   • "Premature end of script headers"

5. # P24 #

   # P25 #

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

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

   • "httpd: caught SIGBUS, attempting to dump core in ..."

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

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

   • ["Server has been running for x hours."]

8. отладка:

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

   • "Opening config file ..."

9. trace1 trace6:

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

   • "proxy: FTP: control connection complete"
   • "прокси: 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:

1. # P37 #

   # P38 #

2. # P39 #

   # P40 #

3. # P41 #

   # P42 #

4. # P43 #

   # P44 #

5. # P45 #

   # P46 #

6. # P47 #

   # P48 #

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

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

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

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

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

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

(Дополнительную информацию см. В руководстве по ведению журнала сообщества.)

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

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

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

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

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

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

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

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

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

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

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

Из 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доброго времени суток,

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

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

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

HTH

Ответ Taco Jan Osinga очень хорош и очень практичен.

Я частично согласен с ним, хотя и с некоторыми вариациями.

В Python есть только 5 именованных уровней ведения журнала, вот как я их использую:

• DEBUG - информация, важная для устранения неполадок и обычно подавляемая при нормальной повседневной работе.
• INFO - повседневная работа как доказательство того, что программа выполняет свои функции, как задумано
• WARN - нестандартная, но исправимая ситуация, * или * столкновение с чем-то, что может привести к проблемам в будущем
• ERROR - произошло что-то, что требует от программы выполнения восстановления, но восстановление выполняется успешно. Однако программа, скорее всего, не находится в первоначально ожидаемом состоянии, поэтому пользователю необходимо будет ее адаптировать.
• CRITICAL - произошло что-то, что не может быть восстановлено, и программа, вероятно, должна быть завершена, чтобы все не жили в состоянии греха

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

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

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

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

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

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

ERROR - это когда возникает НЕИСПРАВНОСТЬ (исключение).

FATAL на самом деле ДВОЙНАЯ ОШИБКА: когда возникает исключение при обработке исключения.

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

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

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

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

Раньше я создавал системы, в которых использовалось следующее:

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

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

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

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

Снимайте все и фильтруйте позже!

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

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

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

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

1. Fatal - что приведет к поломке приложения.
2. Информация - Информация
3. Отладка - менее важная информация