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

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

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

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

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

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

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

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

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

Debug: рассмотрим Debug

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

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

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

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

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

Апач к log4j: §1, §2

1. FATAL:

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

   [П2.0: ..] серьезная ошибка, которая предотвратит применение продолжающий.

2. ERROR:

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

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

3. WARN:

   [В1.2: .. потенциально опасные ситуации.

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

4. INFO:

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

   [П2.0: ..] мероприятие в информационных целях.

5. DEBUG:

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

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

6. TRACE:

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

   [П2.0: ..] мелкозернистое отладочное сообщение, обычно захватывающее поток через приложение.

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

1. emerg:

   аварийные ситуации-система непригодна для использования.

2. предупреждение:

   действие необходимо предпринять немедленно [но система все еще годна к употреблению].

3. Крит:

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

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

4. :

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

   • "преждевременный конец сценария заголовки"

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

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

6. обратите внимание:

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

   • "файл httpd: поймал SIGBUS, пытаясь сбросить ядро ..."

7. info:

   информационных [и unnotable].

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

8. debug:

   Debug-level messages [, т. е. сообщения, зарегистрированные для собирался)].

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

9. trace1 → trace6:

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

   • "прокси-сервер: FTP-сервер: подключение управления полностью"
   • "proxy: 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-ведение журнала:§

1. fatal:

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

2. :

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

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

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

4. info:

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

5. debug:

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

6. след:

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

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

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

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

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

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

• Значительные Внутренние Границы.

(см. commons-руководство по ведению журнала подробнее об этом.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С 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

Добрый день,

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

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

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

HTH

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

1. ошибка-означает, что что-то серьезно не так, и этот конкретный поток/процесс/последовательность не может продолжаться. Требуется некоторое вмешательство пользователя/администратора
2. предупреждение-что-то не так, но процесс может продолжаться, как и раньше (например, одно задание в наборе из 100 не удалось, но остальные могут быть обработаны)

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

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

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

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

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

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

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

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

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

теперь, вы можете выяснить, что может быть смертельным? Ты ведь знаешь, ЧТО ТАКОЕ роковая смерть? Итак, какие пункты в вашем списке фатальны.

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

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

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

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

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

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

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

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

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