Trace, Info, Warning, Error, Fatal — кто все эти люди..?

[jackyodd]

это отлично — это говорит о высоком качестве Вашего приложения, но также существуют продукты/команды, где крэш это «нужно будет глянуть, что там», особенно когда разовый и трудновоспроизводимый

[jackyodd]

А если крэша не будет, но всем этим людям будет показываться красивое сообщение об ошибке «Приложение не работает — обратитесь к администратору» и работу они делать свою не могут — это окей? Можно не спешить?

[jackyodd]

Так. И из этого тогда вроде как получается, что в Вашем проекте даже сообщение об ошибке (не крэш) являются чрезвычайным событием, на которое следует мгновенная реакция команды разработки, которая все бросает и чинит эту проблему. И если Вы можете позволить себе это — т.е. успеваете полностью закрыть причину той ошибки раньше, чем появится новая аналогичная — то это круто, серьезно. Если это так — то в вашем бэклоге сейчас не должно сейчас быть ни единой жалобы от пользователя вроде «Была вот такая ошибка — хотел воспользоваться этой фичей так, как ни одному человеку в голову не придет — почините пжл». А если Вы начинаете выделять «ожидаемые ошибки» как уровень Error — то не кажется ли это странным, что запись об ожидаемом событии имеет более высокий приоритет, чем запись Warning — для неожиданных?

[jackyodd]

Вы точно читали сам текст? Потому что он как бы и есть о том, как уйти от проблемы размытости этих уровней засчет переноса точки зрения с сугубо технических деталей проблемы на реакцию людей на нее. Даже пример с БД есть. Если сервер БД, который упал, находится в ведении вообще другой компании-хостера — и Вы сами не можете с ним сделать ни че го — какова же будет Ваша реакция на такой critical — прям вот не покинете офис, пока бестолочи там не соизволят его наконец поднять?

[jackyodd]

Но Вы же понимаете, что это не единственная возможная схема взаимоотношений? Приложение может делать деньги, но не Вам. Контракт на хостинг БД не с вами, а с компанией, которой Вы продаете услуги разработки. В этом и есть суть описанной идеи — в Вашем сценарии это действительно разумно делать критикал — вы теряете деньги. Но как-то глуповато сидеть и ждать, пока кто-то поднимет упавший сервер, от чего Вам ни холодно ни жарко в рамках существующих договоренностей.
p.s. И честно говоря, я не вижу разницы, из-за чего терять деньги — из-за упавшей БД или опечатке в коде, чтобы иметь для них разные уровни.

[eisaev]

А варианты из RFC5424 (Table 2. Syslog Message Severities) совсем не подходят? Вроде вполне сносно выглядят?

           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

[jackyodd]

как думаете, если у 10 человек спросить, какой уровень выше — Emergency или Critical — все расположат их в правильной очередности без бумажки?

[eisaev]

Если не вспомнит, то есть куда посмотреть. Не стоит думать, что именно ваша схема запомнится всем именно так как её запомнили вы. Но у вашей схемы пока есть один недостаток: если запамятовал, то среди стандартов её не найдёшь.

[event1]

их многовато. Я лично пользуюсь 4-мя: debug, info, warning и error. Видимо для сообщений требующих немедленной реакции (у меня таких не бывает) нужен ещё один выше error, например emergency.
Эти уровни придумали вместе с протоколом syslog в 80-е и получилось неидеально. Пока писал, глянул на logging в питоне. Там сделано так же, как я описал выше

[eisaev]

RFC5424 датирован мартом 2009, но конкретно severity он полностью копирует из RFC3164 от августа 2001. Сами значения конечно же появились ещё раньше, до стандартизации. Возможно стандарт требует переработки, но здесь главное, чтоб не получилось 15 конкурирующих стандартов из того комикса :)

[event1]

но здесь главное, чтоб не получилось 15 конкурирующих стандартов

Боюсь, что уже поздно: java.util.logging.Level, python logging levels, встроенный пакет логирования Go вообще не поддерживает уровней. С другой стороны, все эти реализации живут строго внутри соответствующих экосистем, так что большой беды от этого нет. А если учесть, что для пересылки по сети они, таки, переводятся в syslog, то избыточность уровней в стандарте — это даже и не плохо

[gsaw]

Error в логе это локальный error, не обязательно глобальный, что бы всех на уши ставить. Если библиотека для чтения конфига не может прочитать, то, что вы ей передали в качестве параметра, то она вполне себе может сказать "error: не читается файл такой то", вероятно в самом приложении это детектится и используются настройки по умолчанию, в этом случае приложение может сказать дополнительно "warn: использую настройки по умолчанию". Если не нравится ошибка в библиотеке, то в приложении надо проверить предварительно, есть ли файл с конфигурацией и читаем ли он. Тогда останется только warn приложения. Я по крайней мере таким принципом пользуюсь и не мучаюсь.

[lair]

Буду рад, если этот текст добавит разработчикам больше взаимопонимания и уменьшит споры о том, как "правильно".

Да нет, теперь у нас просто будет еще один вариант "как кто-то думает, что правильно".

У меня вот правило про Fatal четкое: все, что привело к падению или остановке приложения (а у нас честное такое многопользовательское приложение) — это (и только это) Fatal.

[jackyodd]

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

[lair]

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

Ну вот именно потому, что для вас это бессмысленно, а для меня — нет, и продолжатся споры, какой уровень чему ставить.

[jackyodd]

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

[lair]

Чем не могут похвастаться все другие проекты.

Спор как раз в том, что вы думаете, что они себе этого не могут позволить, а они думают, что могут. И объективного способа этот спор разрешить нет.

[jackyodd]

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

[lair]

Если этого не происходит — значит не так уж оно и важно, чтобы там в логах не было написано.

Вот именно потому, что не важно, что в логах написано, можно писать Fatal.

Вы просто почему-то думаете, что Fatal — это все бросили и немедленно переключились. А я думаю, что Fatal — это пользователь не может пользоваться приложением. А вот надо ли бросать и переключаться — это уже не ко мне, а к тем, с кем SLA заключен.

[jackyodd]

Что ж, если решение про «надо бросать и переключаться» или «не надо» — это не к Вам — это многое объясняет. Возможно, когда именно Вам надо будет решать, кому куда переключаться, Вы взглянете на это по другому.

[lair]

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

Вот именно потому, что ответ зависит от того, с какой позиции мы смотрим на вопрос, я и говорю, что объективного ответа нет.

[mm3]

В моём представлении уровни должны выставляться в следующих случаях:
Fatal — ситуация при которой приложение не может продолжать работу и должно быть немедленно остановлено.
Error — ситуация которая не должна была случиться в приложении, требует анализа и должна быть исправлена рано или поздно, в идеале в логе не должно быть ни одной ошибки.
Warning — ситуация которая может потребовать особого внимания, но при этом не является тем, что необходимо исправлять.
Info — минимально необходимая информация необходимая для анализа текущего состояния нормально работающего приложения.
Debug — подробная информация необходимая для отладки приложения, запись обычно включается только на время отладки приложения.
Trace — полное логирование всех входящих и исходящих сообщений в приложении, запись обычно включается только на время отладки приложения.

[jackyodd]

в Вашей системе уведомление о разовой ситуации сбоя, когда пользователь не смог загрузить условный отчет о продажах — увидел экран смерти, затем тупо обновил страницу, загрузил со второй попытки да и забыл, будет выглядеть точно так же, как с пользователем, у которого Вы списали только что сотню баксов с банковской карты, но система слегла на записи в базу факта оплаты. Мой опыт говорит о том, что такие ситуации имеет смысл различать — уж больно разные реакции у людей на эти ситуации, потребовавшие «немедленной остановки приложения».

[mm3]

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

[jackyodd]

Ну да — выбора то не остается в таком случае. Дополнительная отстройка по модулям/компонентам Вам доступна при любой системе записи ошибок. Смотрите, ведь я не хочу сказать никаким образом, что с Вашим подходом что-то не так. Если все упростить, то статья о том, как используя одномерную структуру {Debug ... Critical} добиться того же самого эффекта в плане информирования/реагирования, что и Вы — используя двумерную {Debug... Critical, Component}. Причем цена вопроса с одномерной — нулевая — всего лишь за счет смещения «спектра» значений на одну ступеньку вниз и того факта, что сбои в критичных модулях сами по себе настолько важны, что уже сам уровень ошибки внутри это модуля теряет значение, потому им можно пренебречь.

[lair]

Проблема "одномерной" структуры в том, что она фиксирована. Вы не можете поменять приоритет реагирования на проблему в тот момент, когда система перешла из стейджинга в прод, скажем. А так вы просто настраиваете, что Critical в стейджинге идет в емейл, а в проде — на пейджер.

[jackyodd]

не совсем понял возможно. но то, что Вы описываете, я делаю простым конфигурированием для стейджа и прод. На стейдже в конфиге все в target="Email", на проде условно minLevel='critical' target = "Пейджер" minLevel='warning' maxLevel='error' target= "НеПейджер". (Я в основном по .NET, потому под «target» имеется ввиду target от Nlog бибилиотеки, для Serilog это 'sink' и т.д.)

[lair]

В этот момент этот конфиг и стал вторым измерением.

[jackyodd]

в этом конфиге нет ничего о втором измерении { ..., Component}, о котором речь идет в моем комментарии. Если хотите считать среду за измерение — ну окей, в будет 2d структура {Уровень, Среда} вместо трехмерной {Уровень, Среда, Компонент}.

[netch80]

Ну, у него есть дополнительный смысл, как я понимаю, что для отдельных компонентов можно делать "снижение" уровня при маппинге на общий выход (в каком-то субкомпоненте его Fatal превращается в общий Error, а в каком-то вообще в Warning). Но я не смог с ходу найти вариант, когда такой маппинг надо регулировать в зависимости от режима запуска, так что сомневаюсь в необходимости.
(Хотя может быть, например, деление в зависимости от того, с кем соединение...)

[lair]

Ну, у него есть дополнительный смысл, как я понимаю, что для отдельных компонентов можно делать "снижение" уровня при маппинге на общий выход

У кого "у него"?

[netch80]

У подхода автора статьи.

[lair]

А как добавление промежуточных уровней (а "подход автора статьи" именно в этом) позволяет делать "снижение уровня при маппинге на общий выход"?

[jackyodd]

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

[jackyodd]

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