логика разделения логов по уровням. Я искал что-то стандартное чтобы не изобретать велосипед, но ничего вменяемого не нашел. Есть RFC по syslog, но там описание уровней логирования довольно забавное:
3 Error: error conditions
4 Warning: warning conditions
Что такое warning conditions? Error conditions? Как вы решаете, положить сообщение в info или в debug?
У меня в голове есть определенные паттерны, которые с опытом пришли, но я бы не сказал что выработалась какая-то строгая система.
Навскидку, мы это не формализовывали: * если сообщение в норме возникает реже раза в минуту — info * если при каком-то событии пишется сразу пять связанных сообщений — одно оставить info, остальные по возможности в debug * чаще раза в минуту — скорее дебаг
У меня на проектах так: * debug это то что нужно видеть разработчику во время локального запуска, на проде он даже не собирается. * info пишется когда что-то просто происходит, это не обязательно ошибка или что-то на что нужно обратить внимание. Например, какой-нибудь периодический воркер исполняет свою джобу или там юзера забанили * warning и error когда нужно отреагировать на лог как-то. То есть там соединение к стороннему сервису отвалилось или диск заканчивается или что-то такое
для начала вопрос: логи для кого? Кто их будет читать? Если это сторонний программист, значит берешь какой-то способ фиксирования схем и делаешь структурированные евенты, после чего они перестают называться логами, а называются евентами и кладутся в кафку Если это такой разработчик, которого называют админом, то по сути — всё будет дебаг информацией
debug То, чего не должно быть на проде info Отладка каких-то ситуаций на проде. Например: важный воркер запустился, ну и хорошо. А вот если что-то сломалось, лезем через неделю в логи и смотрим, когда важный воркер перестал запускаться. --- то есть при отключении debug и info на проде важная инфа не пострадает warning всё плохо, но можно починить и ничего не упало error срочно всем звонить, писать смски, телеги и генеральному!
Обсуждают сегодня