Когда использовать разные уровни журнала
Есть разные способы записи сообщений в порядке фатальности:
FATALERRORWARNINFODEBUGTRACE
Как мне решить, когда использовать какой?
Что такое хорошая эвристика для использования?
22 ответа
Я обычно подписываюсь под следующим соглашением:
- Трассировка - только когда я "отслеживаю" код и пытаюсь найти определенную часть функции.
- Отладка - информация, которая диагностически полезна людям больше, чем просто разработчикам (ИТ, системным администраторам и т. Д.).
- Информация - обычно полезная информация для регистрации (запуск / остановка службы, предположения о конфигурации и т. Д.). Информация, которую я хочу всегда иметь в наличии, но обычно меня не волнует в обычных обстоятельствах. Это мой стандартный конфигурационный уровень.
- Предупреждать - все, что может вызвать странные странности приложения, но для которого я автоматически восстанавливаюсь. (Например, переключение с основного на резервный сервер, повторение операции, отсутствие дополнительных данных и т. Д.)
- Ошибка - любая ошибка, которая является фатальной для операции, но не для службы или приложения (невозможно открыть необходимый файл, отсутствуют данные и т. Д.). Эти ошибки приведут к вмешательству пользователя (администратора или непосредственного пользователя). Обычно они зарезервированы (в моих приложениях) для неправильных строк подключения, отсутствующих служб и т. Д.
- Неустранимый - любая ошибка, которая вызывает принудительное завершение работы службы или приложения, чтобы предотвратить потерю данных (или дальнейшую потерю данных). Я оставляю их только для самых отвратительных ошибок и ситуаций, в которых гарантировано повреждение или потеря данных.
Хотели бы вы, чтобы это сообщение доставляло системного администратора из постели среди ночи?
- да -> ошибка
- нет -> предупредить
Это старая тема, но все еще актуальная. На этой неделе я написал об этом небольшую статью для своих коллег. Для этой цели я также создал эту шпаргалку, потому что я не мог найти ее в Интернете.
Я считаю более полезным думать о серьезности с точки зрения просмотра файла журнала.
Неустранимый / Критический: Общий сбой приложения или системы, который следует немедленно расследовать. Да, разбуди Сисадмина. Поскольку мы предпочитаем, чтобы наши SysAdmins были предупреждены и хорошо отдохнули, эту серьезность следует использовать очень редко. Если это происходит ежедневно, и это не BFD, значит, оно потеряно. Как правило, неустранимая ошибка возникает только один раз за время существования процесса, поэтому, если файл журнала связан с процессом, это, как правило, последнее сообщение в журнале.
Ошибка: определенно проблема, которая должна быть исследована. SysAdmin должен быть уведомлен автоматически, но его не нужно тащить с кровати. Фильтруя журнал для просмотра ошибок и выше, вы получаете обзор частоты ошибок и можете быстро определить первоначальный сбой, который мог привести к каскаду дополнительных ошибок. Отслеживание частоты ошибок по сравнению с использованием приложения может дать полезные показатели качества, такие как MTBF, которые можно использовать для оценки общего качества. Например, этот показатель может помочь в принятии решений о том, нужен ли еще один цикл бета-тестирования перед выпуском.
Предупреждение: это МОЖЕТ быть проблемой, а может и нет. Например, ожидаемые переходные условия окружающей среды, такие как кратковременная потеря подключения к сети или базе данных, должны регистрироваться как предупреждения, а не ошибки. Просмотр журнала, отфильтрованного для отображения только предупреждений и ошибок, может дать быстрое представление о ранних подсказках об основной причине последующей ошибки. Предупреждения следует использовать с осторожностью, чтобы они не стали бессмысленными. Например, потеря доступа к сети должна быть предупреждением или даже ошибкой в серверном приложении, но это может быть просто информация в настольном приложении, предназначенном для время от времени отключенных пользователей ноутбуков.
Информация: это важная информация, которая должна регистрироваться при нормальных условиях, таких как успешная инициализация, запуск и остановка служб или успешное завершение значительных транзакций. Просмотр журнала с информацией и выше должен дать краткий обзор основных изменений состояния в процессе, предоставляя контекст верхнего уровня для понимания любых предупреждений или ошибок, которые также происходят. Не иметь слишком много информационных сообщений. Обычно у нас есть < 5% информационных сообщений относительно трассировки.
Трассировка: Трассировка является наиболее часто используемой серьезностью и должна предоставлять контекст для понимания шагов, приводящих к ошибкам и предупреждениям. Правильная плотность сообщений Trace делает программное обеспечение более удобным в обслуживании, но требует некоторого усердия, потому что значение отдельных операторов Trace со временем может изменяться по мере развития программ. Лучший способ добиться этого - заставить команду разработчиков регулярно просматривать журналы как стандартную часть устранения неполадок, о которых сообщают клиенты. Поощряйте команду удалять сообщения трассировки, которые больше не предоставляют полезный контекст, и добавлять сообщения, где это необходимо, чтобы понять контекст последующих сообщений. Например, часто полезно регистрировать пользовательский ввод, такой как изменение отображения или вкладок.
Debug: мы считаем, Debug
Вот список того, что есть у "регистраторов".
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 (как обычно) любит идти на перебор: §
Emerg:
Чрезвычайные ситуации - система неработоспособна.
оповещение:
Действие должно быть предпринято немедленно [но система все еще пригодна для использования].
крит:
Критические условия [но действия не должны быть предприняты немедленно].
- " сокет: не удалось получить сокет, выход из дочернего процесса "
ошибка:
Условия ошибки [но не критично].
- " Преждевременный конец заголовков скриптов "
предупредить:
Условия предупреждения. [близко к ошибке, но не к ошибке]
уведомление:
Нормальное, но значительное [ заметное ] состояние.
- " httpd: пойман
SIGBUS, пытаясь сбросить ядро в... "
- " httpd: пойман
информация:
Информационный [и неизвестный].
- [" Сервер работает в течение x часов. "]
отладка:
Сообщения уровня отладки [то есть сообщения, зарегистрированные для устранения ошибок)].
- " Открытие файла конфигурации... "
trace1 → trace6:
Сообщения трассировки [т.е. сообщения, зарегистрированные для отслеживания ].
- " прокси: FTP: управляющее соединение установлено "
- " proxy: CONNECT: отправка запроса CONNECT на удаленный прокси "
- " openssl: рукопожатие: начало "
- " чтение из буферизованной бригады SSL, режим 0, 17 байт "
- " Поиск по карте НЕ УКАЗАН:
map=rewritemapkey=keyname" - " Сбой поиска в кэше, форсированный поиск новой карты "
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: §
фатальный:
Серьезные ошибки, которые вызывают преждевременное завершение. Ожидайте, что они будут немедленно видны на консоли состояния.
ошибка:
Другие ошибки во время выполнения или неожиданные условия. Ожидайте, что они будут немедленно видны на консоли состояния.
предупредить:
Использование устаревших API, плохое использование API, "почти" ошибки, другие ситуации времени выполнения, которые нежелательны или неожиданны, но не обязательно "неправильны". Ожидайте, что они будут немедленно видны на консоли состояния.
информация:
Интересные события во время выполнения (запуск / выключение). Ожидайте, что они будут немедленно видны на консоли, поэтому будьте консервативны и соблюдайте минимум.
отладка:
подробная информация о потоке через систему. Ожидайте, что они будут записаны только в журналы.
трассировка:
более подробная информация. Ожидайте, что они будут записаны только в журналы.
В "лучших практиках" использования корпоративной логики Apache проводится различие между отладкой и информацией в зависимости от того, какие границы они пересекают.
Границы включают в себя:
Внешние границы - ожидаемые исключения.
Внешние границы - неожиданные исключения.
Внутренние Границы.
Значимые внутренние границы.
(Для получения дополнительной информации см. Руководство по ведению общего журнала.)
Я бы рекомендовал принять уровни серьезности Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY,
Смотрите http://en.wikipedia.org/wiki/Syslog
Они должны обеспечивать достаточные уровни детализации для большинства случаев использования и распознаются существующими анализаторами журналов. Хотя у вас, конечно, есть свобода реализации только подмножества, например, DEBUG, ERROR, EMERGENCY в зависимости от требований вашего приложения.
Давайте стандартизируем что-то, что существует уже целую вечность, вместо того, чтобы придумывать собственный стандарт для каждого отдельного приложения, которое мы делаем. Как только вы начинаете собирать журналы и пытаетесь обнаружить шаблоны по разным, это действительно помогает.
Если вы можете решить проблему, то это предупреждение. Если это мешает продолжить выполнение, то это ошибка.
Предупреждения вы можете восстановить. Ошибки вы не можете. Это моя эвристика, у других могут быть другие идеи.
Например, допустим, вы вводите / импортируете имя "Angela Müller" в ваше приложение (обратите внимание на умлаут над u). Ваш код / база данных может быть только на английском языке (хотя, вероятно, не должно быть в наши дни и в таком возрасте) и поэтому может предупредить, что все "необычные" символы были преобразованы в обычные английские символы.
Сравните это с попыткой записать эту информацию в базу данных и получить сообщение об отсутствии сети в течение 60 секунд подряд. Это скорее ошибка, чем предупреждение.
Из 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
Интересно, как Microsoft определяет различные значения LogLevel в своем новом «квазистандарте».Microsoft.Extensions.Logging(выделено мной):
Критический
Журналы, описывающие неустранимый сбой приложения или системы или катастрофический сбой, требующий немедленного вмешательства.
Ошибка
Журналы, которые выделяют, когда текущий поток выполнения останавливается из-за сбоя. Они должны указывать на сбой в текущем действии, а не на сбой всего приложения .
Предупреждение
Журналы, которые выделяют ненормальное или неожиданное событие в потоке приложения, но не приводят к остановке выполнения приложения.
Информация
Журналы, которые отслеживают общий поток приложения. Эти журналы должны иметь долгосрочную ценность .
Отлаживать
Журналы, которые используются для интерактивного исследования во время разработки. Эти журналы должны в первую очередь содержать информацию, полезную для отладки, и не иметь долгосрочной ценности .
След
Журналы, содержащие наиболее подробные сообщения. Эти сообщения могут содержать конфиденциальные данные приложения . Эти сообщения отключены по умолчанию и никогда не должны включаться в производственной среде .
Ответ Тако Яна Осинга очень хорош и очень практичен, кстати.
Я частично согласен с ним, хотя и с некоторыми вариациями.
В Python есть только 5 "именованных" уровней ведения журнала, поэтому я их использую следующим образом:
-
DEBUG- информация, важная для устранения неполадок и обычно подавляемая при обычной повседневной работе -
INFO- повседневная работа как "доказательство" того, что программа выполняет свои функции, как задумано -
WARN- нештатная, но исправимая ситуация, * или * столкновение с чем-то, что может привести к проблемам в будущем -
ERROR- что - то случилось, что требует программы, чтобы сделать восстановление, но восстановление является успешным. Тем не менее, программа, скорее всего, не находится в первоначально ожидаемом состоянии, поэтому пользователю необходимо будет ее адаптировать. -
CRITICAL- произошло что-то, от чего нельзя избавиться, и программа, вероятно, должна быть остановлена, чтобы все не жили в состоянии греха
Из https://sematext.com/blog/slf4j-tutorial/:
- TRACE — события журнала с этим уровнем являются наиболее детализированными и обычно не нужны, если только вам не требуется полная видимость того, что происходит в вашем приложении и внутри сторонних библиотек, которые вы используете. Вы можете ожидать, что уровень ведения журнала TRACE будет очень подробным.
- DEBUG — менее детализированный по сравнению с уровнем TRACE, но все же больше, чем вам понадобится в повседневном использовании. Уровень журнала DEBUG следует использовать для информации, которая может понадобиться для более глубокой диагностики и устранения неполадок.
- INFO — стандартный уровень журнала, указывающий, что что-то произошло, приложение обработало запрос и т. д. Информация, регистрируемая с использованием уровня журнала INFO, должна быть чисто информативной, и непросматривание их на регулярной основе не должно приводить к пропуску какой-либо важной информации.
- WARN — уровень журнала, указывающий, что в приложении произошло что-то непредвиденное. Например, проблема или ситуация, которая может нарушить работу одного из процессов, но все приложение продолжает работать.
- ОШИБКА — уровень журнала, который следует использовать, когда приложение сталкивается с проблемой, препятствующей правильной работе одной или нескольких функций. Уровень журнала ERROR можно использовать, когда одна из платежных систем недоступна, но есть возможность проверить корзину в приложении электронной коммерции или когда по какой-то причине не работает ваша опция ведения журнала в социальных сетях. Вы также можете увидеть уровень журнала ERROR, связанный с исключениями.
Я полностью согласен с другими и считаю, что GrayWizardx сказал это лучше всего.
Все, что я могу добавить, - это то, что эти уровни обычно соответствуют их словарным определениям, так что это не так сложно. Если сомневаетесь, относитесь к нему как к головоломке. Для вашего конкретного проекта, подумайте обо всем, что вы можете захотеть войти.
Теперь вы можете выяснить, что может быть смертельным? Вы знаете, что означает фатале, не так ли? Итак, какие элементы в вашем списке смертельны.
Хорошо, это фатальная проблема, теперь давайте посмотрим на ошибки... промыть и повторить.
Ниже Fatal, или, возможно, Error, я бы предположил, что больше информации всегда лучше, чем меньше, поэтому ошибка "вверх". Не уверен, что это информация или предупреждение? Тогда сделайте это предупреждением.
Я думаю, что фатальные ошибки и ошибки должны быть понятны всем нам. Другие могут быть нечеткими, но, возможно, менее важно понять их правильно.
Вот некоторые примеры:
Неустранимый - не может выделить память, базу данных и т. Д. - не может продолжаться.
Ошибка - нет ответа на сообщение, транзакция прервана, невозможно сохранить файл и т. Д.
Предупреждение - распределение ресурсов достигает X% (скажем, 80%) - это признак того, что вы можете изменить размер вашего.
Информация - пользователь вошел / вышел, новая транзакция, файл создан, новое поле d/b или поле удалено.
Отладка - дамп внутренней структуры данных, уровень Anything Trace с именем файла и номером строки.
Trace - действие выполнено / не выполнено, d/b обновлено.
Как уже говорили другие, ошибки - это проблемы; предупреждения являются потенциальными проблемами.
В процессе разработки я часто использую предупреждения, в которые я могу поместить эквивалент ошибки подтверждения, но приложение может продолжать работать; это позволяет мне узнать, случается ли когда-либо этот случай на самом деле, или это мое воображение.
Но да, это сводится к аспектам восстановления и актуальности. Если вы можете восстановить, это, вероятно, предупреждение; если что-то действительно приводит к сбою, это ошибка.
Я думаю, что уровни SYSLOG NOTICE и ALERT/EMERGENCY в значительной степени излишни для ведения журналов на уровне приложения - в то время как CRITICAL/ALERT/EMERGENCY могут быть полезными уровнями оповещения для оператора, который может инициировать различные действия и уведомления, для администратора приложения это все равно, что и для администратора приложения. FATAL. И я просто не могу достаточно различить, когда мне дают уведомление или какую-то информацию. Если информация не заслуживает внимания, это не совсем информация:)
Мне больше всего нравится интерпретация Джея Синкотты - отслеживание исполнения вашего кода является чем-то очень полезным в технической поддержке, и следует поощрять произвольное включение операторов трассировки в код - особенно в сочетании с механизмом динамической фильтрации для регистрации сообщений трассировки от определенных компонентов приложения. Однако уровень DEBUG для меня указывает на то, что мы все еще находимся в процессе выяснения того, что происходит - я вижу вывод уровня DEBUG только для разработки, а не как то, что должно когда-либо отображаться в производственном журнале.
Однако есть уровень ведения журнала, который я хотел бы видеть в своих журналах ошибок при ношении шапки сисадмина, а также техподдержки или даже разработчика: OPER для сообщений OPERATIONAL. Это я использую для регистрации метки времени, типа вызванной операции, предоставленных аргументов, возможно (уникального) идентификатора задачи и завершения задачи. Он используется, когда, например, запускается отдельная задача, что является истинным вызовом из более крупного долго работающего приложения. Это то, что я хочу всегда регистрировать, независимо от того, идет что-то не так или нет, поэтому я считаю, что уровень OPER выше, чем FATAL, так что вы можете отключить его, только перейдя в полностью тихий режим. И это намного больше, чем просто данные журнала INFO - уровень журнала, который часто используют для рассылки спама с незначительными операционными сообщениями, не имеющими никакой исторической ценности.
В зависимости от ситуации эта информация может быть направлена в отдельный журнал вызовов или может быть получена путем фильтрации ее из большого журнала, в котором записано больше информации. Но всегда, как историческая информация, всегда нужно знать, что было сделано - без опускания до уровня AUDIT, другого совершенно отдельного уровня журнала, который не имеет ничего общего с неисправностями или работой системы, на самом деле не вписывается в вышеуказанные уровни (поскольку ему нужен собственный управляющий переключатель, а не классификация по серьезности), а для него, безусловно, нужен собственный отдельный файл журнала.
G'day,
Как следствие к этому вопросу, сообщите свои интерпретации уровней журнала и убедитесь, что все люди в проекте согласованы в своей интерпретации уровней.
Больно видеть огромное разнообразие сообщений журнала, в которых уровни серьезности и выбранные уровни журнала несовместимы.
Приведите примеры, если это возможно, различных уровней ведения журнала. И будьте последовательны в информации для входа в сообщение.
НТН
Мои два цента примерно FATAL а также TRACE уровни журнала ошибок.
ERROR это когда происходит некоторая НЕИСПРАВНОСТЬ (исключение).
FATAL на самом деле ДВОЙНАЯ ОШИБКА: когда возникает исключение при обработке исключения.
Для веб-службы это легко понять.
- Запрос пришел. Событие регистрируется как
INFO - Система обнаруживает нехватку места на диске. Событие регистрируется как
WARN - Для обработки запроса вызывается какая-то функция. При обработке происходит деление на ноль. Событие регистрируется как
ERROR - Для обработки деления на ноль вызывается обработчик исключений веб-службы. Веб-сервис / фреймворк собирается отправлять электронную почту, но не может, потому что почтовая служба сейчас отключена. Это второе исключение нельзя обработать обычным образом, потому что обработчик исключений веб-службы не может обработать исключение.
- Вызван другой обработчик исключений. Событие регистрируется как
FATAL
TRACEэто когда мы можем отслеживать вход / выход из функции. Речь идет не о ведении журнала, потому что это сообщение может быть сгенерировано каким-либо отладчиком, и ваш код не обращается кlogсовсем. Таким образом, сообщения, которые не из вашего приложения, помечаются какTRACEуровень. Например, вы запускаете свое приложение с помощьюstrace
Итак, обычно в вашей программе вы делаете DEBUG, INFO а также WARNВедение журнала. И только если вы пишете какой-нибудь веб-сервис / фреймворк, вы будете использоватьFATAL. И когда вы отлаживаете приложение, вы получитеTRACE ведение журнала из этого типа программного обеспечения.
Кстати, я большой поклонник захвата всего и фильтрации информации позже.
Что произойдет, если вы выполняете захват на уровне "Предупреждение" и хотите получить некоторую информацию об отладке, связанную с предупреждением, но не смогли восстановить предупреждение?
Захватите все и отфильтруйте позже!
Это справедливо даже для встроенного программного обеспечения, если только вы не обнаружите, что ваш процессор не успевает за ним, в этом случае вы можете захотеть изменить дизайн трассировки, чтобы сделать ее более эффективной, или трассировка мешает синхронизации (вы можете рассмотреть возможность отладки на более мощный процессор, но он открывает еще одну банку с червями).
Захватите все и отфильтруйте позже!!
(Кстати, захватывать все также хорошо, потому что это позволяет вам разрабатывать инструменты, которые делают больше, чем просто показывают трассировку отладки (я рисую из себя таблицы последовательности сообщений и гистограммы использования памяти. Это также дает вам основу для сравнения, если что-то пойдет не так в будущее (сохранить все журналы, независимо от того, пройдены они или нет, и обязательно включите номер сборки в файл журнала)).
Я всегда думал о том, чтобы предупредить первый уровень журнала, который наверняка означает, что есть проблема (например, возможно, файл конфигурации не там, где он должен быть, и нам придется работать с настройками по умолчанию). Для меня ошибка подразумевает, что то, что означает, что основная цель программного обеспечения теперь невозможна, и мы попытаемся аккуратно завершить работу.
Ошибка - это что-то, что является неправильным, просто неправильным, никак не обойтись, ее нужно исправить.
Предупреждение - это признак того, что шаблон может быть неправильным, но в то же время может и не быть.
Сказав это, я не могу придумать хороший пример предупреждения, которое также не является ошибкой. Под этим я подразумеваю, что если вы попытаетесь записать предупреждение, вы также можете решить основную проблему.
Однако такие вещи, как "выполнение sql занимает слишком много времени", могут быть предупреждением, в то время как "тупики выполнения sql" являются ошибкой, так что, возможно, в некоторых случаях все-таки есть.
Я построил системы до этого, используя следующее:
- ОШИБКА - означает, что что-то серьезно не так, и этот конкретный поток / процесс / последовательность не может продолжаться. Требуется вмешательство пользователя / администратора
- ВНИМАНИЕ - что-то не так, но процесс может продолжаться, как и раньше (например, одно задание из набора 100 не выполнено, но остальное можно обработать)
В системах, которые я построил, администраторы получали инструкции реагировать на ОШИБКИ. С другой стороны, мы будем отслеживать ПРЕДУПРЕЖДЕНИЯ и определять для каждого случая, требуются ли какие-либо системные изменения, перенастройки и т. Д.
Предлагаю использовать только три уровня
- Fatal - что приведет к поломке приложения.
- Информация - Информация
- Отладка - менее важная информация