Комментарии 2
Объяснение всегда выглядит логичным при правильно подобранных примерах.
В вашем случае все выглядит логичным и понятным, но, например, вдруг кому-то приходит задача, в которой он, ну вот так вышло, хочет видеть уровень "SUCCESS". Может быть иногда ему пользователь деньги платит и он хочет это видеть подсвеченным зеленым в логах… И с его точки зрения Success не тождественно вашему Notice.
А кому-то недостаточно уровня Debug, куда он выводит только человекочитаемые заметки, но еще нужен уровень Trace, в который он будет время от времени скидывать содержимое стека для отладки (или содержимое переменной, обязательно в JSON или даже бинарном виде).
(да, запись в отдельный лог — это какой-то выход, но до тех пор, пока вам не надо будет это объединить. Тогда уж и каждый уровень в свой лог пишите)
Это мы еще о простом случае когда разработчики согласны договориться об одних и тех же уровнях. А не тогда, когда одному ваш Notice — это уже Warning, а другой не хочет столько варнингов видеть в логах. Так можно договориться уже и до второго этажа логирования, когда внутри уровня мы еще какие-то метки ставим для фильтрации.
но еще нужен уровень Trace
Наверное стоило уточнить в статье, что речь про уровни используемые на продакшн. Trace для отладки я как-то само-собой разумеющимся посчитал. Хотелось заострить внимание на том, что Debug нужен именно для «боевого» применения, т.к. обычно схожие статьи выдают ему роль «только для отладки».
И с его точки зрения Success не тождественно вашему Notice.
Если в моей статье и есть какая-то ценность, то она как раз именно в том, что и с моей точки зрения его Success не равен Notice, так как есть принцип, по которому их относительно легко и однозначно ранжируем.
задача, в которой он, ну вот так вышло, хочет видеть уровень «SUCCESS»
Если вопрос в том, как зеленым строчку с success подсветить, то я не вижу ничего плохого в «подгруппах» событий в рамках одного уровня. По факту, у меня для Info есть как минимум 3 расширения: InfoAsStart, InfoAsFinish, InfoAsSuccess — я бы помечал Success записи флагом, чтобы потом отрисовщики событий могли их разукрашивать в зеленый. И это уже выводится на уровень конфигурирования, т.е. кому надо — видит зеленым, кому не надо — и так сойдет.
Если вопрос именно о принципе, когда хочется акцентировать внимание на условно положительных событиях вместо негативных, то мне кажется это довольно синтетическим сценарием. Внимание человека, наблюдающего за системой, я принимаю за ограниченный ресурс и не вижу смысла выдавать более высокий приоритет тому, на что заведомо не стоит тратить внимание при прочих равных. Может быть такой сценарий и найдется, но это явно будет исключение, а в типичном случае «негативные» событие разумнее рассматривать первыми.
Алгоритм ранжирования ошибок