Существует ли практически согласованное руководство по уровням журналов?

Question

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

• Fatal - Ваше приложение закрывается.
• Ошибка - эта операция или поток аварийно завершает работу и горит. Приложение может продолжить работу.
• Предупреждать - текущая операция может продолжаться, но инженеру необходимо что-то исследовать.
• Информация - Объясните, что делает ваша операция.
• Отладка - Объяснение операций, которые могут получить довольно спам (внутренние циклы и т. Д.).

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

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

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

Answer 1

Я даже не уверен, что можно ли объективно ответить на вопрос, является ли что-то «весьма согласованным».

Библиотеки Log4j и Log4Net , безусловно, используют определения уровней, которые вы описали. Смотрите эту ссылку .

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

Answer 2

из SSCLI (источники .NET):

namespace System {
    ...
    [Serializable]
    internal enum LogLevel {
        Trace  = 0,
        Status = 20,
        Warning= 40,
        Error  = 50,
        Panic  = 100,
    }
    ...
}

обратите внимание на значения [warning]) Я полагаюсь на этот вариант распределения. в любом случае это Microsoft)

Answer 3

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

Я бы добавил пару предостережений:

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

• Категории обязательно субъективны, но с использованием языкакак «падение и сгорание» может привести к недоразумению.

• На практике использование может не соответствовать стилю defacto;Например, некоторые системы ведения журналов позволяют использовать другие (не манифестные) уровни, а разработчики могут регистрировать события на «неправильном» уровне.

---

Обратите внимание, что в slf4j 1.4 добавлена ​​поддержкауровень TRACE.

Answer 4

Думаю, что я добавлю уровни из средства ведения журнала Python:

DEBUG - Подробная информация, обычно представляющая интерес только при диагностике проблем.

INFO - Подтверждение того, что все работает, как ожидалось.

ПРЕДУПРЕЖДЕНИЕ. Указывает на то, что произошло что-то непредвиденное, или указывает на наличие проблемы в ближайшем будущем (например, «недостаточно места на диске»).Программное обеспечение по-прежнему работает должным образом.

ОШИБКА - из-за более серьезной проблемы программное обеспечение не может выполнить какую-либо функцию.

КРИТИЧЕСКАЯ - серьезная ошибка, указывающая, что программасамо по себе может быть не в состоянии продолжить работу.

Их можно найти здесь: http://docs.python.org/howto/logging.html#logging-basic-tutorial