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

Question

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

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

G'day,

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

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

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

НТН

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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