отражалось на производительности приложения хоть в какой-то ощутимой степени, надо логировать вообще всё подряд. И то, с учётом всяких сетевых издержек не уверен, что даже так можно будет увидеть разницу между логгерами в плане их производительности
Именно. Ни разу нигде не упирался в производительность логгера
Я вот прям упирался, где был конвеер обработки данных, сразу после перехода на zap взлетело почти как в бенчмарках раза в 3
А логи куда пишутся? В файл что ли?
stdout а там лог экспортер
Логировать надо всё, что необходимо для того, чтобы разобраться в баге потом. Это довольно дофига
Ключевое тут "в баге". Логировать баги != логировать всё подряд
Зависит от того, что считать багом
Вам нужен error handling и panic recovery в частности
Ну так там и логировать - то есть тогда, когда ошибка или паника
Вы тоже заранее знаете, где у вас баги? И предусмотрительно паникуете
Я не знаю заранее, где у меня баги. Но если они появляются, я знаю где их искать. В чем вопрос?
Вы беспрерывно смотрите тонны логов, чтобы заметить там баги? Или же вам о баге приходит инфа со стороны (от тестеров, от юзеров и т.п.)? Если второе, то что мешает по необходимости добавить отладочное логирование для выявления причины бага, а потом его убрать (или изменить уровень логирования), чтобы не превращать логи в помойку?
- а если баг не повторяется? - а какие данные нужны чтобы повторить баг? - а какой контекст был когда был баг? как ответить и откуда взять данные на эти и еще 100500 вопросов, которые возникают, когда баг это больше чем просто “забыл переменную передать”?
Ну почему же непрерывно, когда дежурю. Чтобы не тестировать изменение, катить бекенд, потом ждать воспроизведения. Что значит "помойку"? Логи должны выполнять свою задачу, а не для галочки быть
Обсуждают сегодня