Comments 15
Самое обидное что вот в 2025 году люди делают статью в которой продвигают logrus который устарел примерно в момент создания.
Осталась самая малость - свести три записи в одну, добавить request_id (потому что клиент мог и не один раз запросить расчет), вместо фио и прочего ПД вставить client_id... Потом, возможно , сделать вложенные структуры - отдельно коэффициенты по возрасту, сумме и чему-то ещё, отдельно инфа от антифрода, ... )
Да, ещё разработать нормальную архитектуру сервиса, а не писать всё в одном файлике, написать автотесты, настроить CI/CD, прикрутить кубер…для объяснения простых вещей, которые не так часто встречаются в реальных системах вполне достаточно и такого объяснения. А там уже у кого на что фантазии хватит… если думаете, что такое решение можно скопипастить и юзать на проде, то глубоко ошибаетесь :) это пример, он максимально упрощён.
Думаю, что лучше использовать slog, который обеспечивает структурированное логирование. Согласен, что и на каком уровне логировать - иногда нетривиальная задача.
Хорошая заметка, спасибо.
А у вас нет желания добавить примеры с неким middleware, который бы заранее обогащал данные для записи в журнал, скажем тод-же `request-id` ?
В заголовке статьи обещают откровения о логах, а в тексте трассировку зачем-то переизобретают...
Я понимаю задачу и понимаю автора, но не понимаю что за задачу надо решать в реальной жизни.
Поясняю. Данный пример можно решить таким способом, но это задача в вакууме. Если мы в реальный мир выходим, то все таки описанная задача будет решаться базой с транзакционной моделью для сохранения консистентности данных.
Самое печальное вообще в самом примере, что независимо от пакета при вызове log.{что-то там}() приходим к fmt пакету. Т.е функции которая выполняется и тратит такты на свою работу и тормозит общий поток. Тут предлагается сделать еще агрегирование лога (т.е еще больше ресурсов потратить) чтобы что? Чтобы удобно было по grep поискать?
Да вы можете сказать, заверни ее в буф канал и будете правы. Только вот в чем вопрос, а если у вас буф канал на log, то зачем вам вообще лог подобного формата в файле. Т.е буф канал сразу ставит крест на том что это критически важные логи, т.к если будет паника - поток падает и часть лога в буф канале исчезнет
Отсюда можно сделать очень простой вывод: либо лог нужен для того чтобы отслеживать состояние программы, с минимальными нагрузками до состояния чек-поинтов чтобы в критической ситуации понять где сбой (точнее после чего) без создания очереди, либо использовать что-то другое в том числе базы данных где тупо оптимизация и стабильность выше и можно хоть миллионами запросов пулять.
спасибо автору что поделился своим видением, но противник идей где логи являются bottleneck производительности. И не знаю как другие делают, а у нас даже сборки отдельные //go:build !debug чтобы инструкции log.Debug просто вырезались при компиляции и лишнюю нагрузку не вызывали.
PS: я тут код посмотрел, пф, понимаю что он для примера..но ептить, там аллокация на аллокации, и аллокацией погоняет. Имхо мне бы стыдно было такой код показывать, но пускай остается на совести автора.
С облегчением! :) но это нужно не в комментах делать
Я надеялся что в ответе вы расскажите куда ваше решение можно использовать и самое главное как в тяжелом проде. Но видимо я попал в статью теоретика, а не практика.
И вас с облегчением, раз вы написали статью в раздел мнения, а другие мнения вам не интересны
Я бы с радостью, да в статье конкретное решение не предлагается, чтобы его где-то использовать. Описывается подход. В комментариях имеет смысл приводить конкретные факты, которые относятся к теме статьи. В данном случае факты должны либо обоснованно опровергать подход, либо дополнять. А своё мнение пишите в своих статьях, что-то у вас их совсем нет :)
Go: логирование