Pull to refresh

Comments 24

Используйте if (log.IsDebugEnabled) [...] Обычно отладочных сообщений в коде много и, если их не накрывать таким if-ом, они могут сильно просадить скорость выполнения.

Это же на уровне логгера должно делаться вроде как (и Serilog это прекрасно делает, кстати). Если это надо делать в прикладном коде, с логированием что-то фундаментально не так.

Ну у вас же идёт вызов log.DebugFormat("...", value1, value2, value3). Он же не бесплатно делается. он же собирает параметры в массив, который надо создать.
Всё что может сделать serilog это не делать свою обработку, но стоимость простого вызова метода никто не отменял

Конкретно взятый серилог эту проблему решает так: https://github.com/serilog/serilog/blob/v2.10.0/src/Serilog/Core/Logger.cs#L229


Если инфраструктура фотона так не делает, значит одно из двух: или эта потеря производительности на самом деле не важна (как в Microsoft.Extensions.Logging; еще точнее, там это просто сделано другим образом), или они не подумали, а должны были.

ну смотрите, там решение для трёх параметров, 4 уже будут стоить дороже. Так как решение действительно изящное и нужное, я думаю, что его можно будет добавить, но тем не менее в общем случае я бы всё равно использовал предварительную проверку.

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

Необходимость постоянно писать избыточный код плохо говорит о фреймворке. Посмотрите, как сделано в M.E.L.

Вопрос у меня. Вы используете в логгировании интерполяцию строк?

Нет, конечно. Зачем?

нахожу это сильно удобнее чем {0}...{1}. Особенно, если надо отредактировать сообщение
ну т.е. вы только serilog используете, так?

Где на практики плюсы. Я бегло посомтрел в файл, там в общем-то тоже самое, как если бы я log4net пользовался
ну т.е. вы только serilog используете, так?

Нет, конечно. Еще я использую Microsoft.Extensions.Logging.


Где на практики плюсы.

На практике плюсы там, где вы пишете в структурированное хранилище, начиная с JSON-файлов, и заканчивая AWS CloudWatch, Elasticsearch и Seq. А потом при анализе логов просто говорите "ага, хочу все логи от такого-то запроса для такого-то компонента для такого-то токена".


Я бегло посомтрел в файл, там в общем-то тоже самое, как если бы я log4net пользовался

… в обычный текстовый файл, наверное? Нет, там вы плюсов не найдете.

Интересно почему делегаты не завезли как в NLog
_logger.Info(() => string.Format("msg", myParams));

Потому что еще не факт, что создание (и потенциальный вызов) делегата дешевле, чем создание массива.

Тут надо понимать, что когда фотон начали разрабатывать, из библиотек, которым можно было бы доверять был только log4net ну и может быть nlog в своих первых версиях. выбрали log4net. Апач, опер сорс, сообщество разработчиков. nlog писал никому неизвестный парнишка. кто ж знал тогда, что log4net перестанет развиваться.

Базовый интерфейс логгера был сделан на основе log4net. И его в общем-то не трогали, потому что свою работу он делал.

ну и согласен с lair, что эффективность такого подхода сомнительна
Но это не значит что все им должны пользоваться.

Я удивлен, что им вообще до сих пор еще кто-то пользуется :)

:) Ну да. Слишком много всего сделано было, чтобы получить нужный нам результат. И чтобы съехать на другой фреймворк надо это переделать.

Для этого достаточно было просто изначально не использовать его напрямую, а за самое большее человеко-час труда слепить простую обертку (что, для логирования всегда было best practice).

вы делаете суждения не разобравшись
Чтобы не быть голословным поясню, что я имею в виду.
Допустим у вас есть какой-то адаптер созданный за час. И вы пользуетесь serilog. Благодаря адаптеру, в любой момент вы можете подсунуть другой. Но это только в начале. Потому что потом выяснится, что, чтобы использовать мощь serilog, строки сообщений были сформированы под структурное логгирование. Потом вам где-то пришлось использовать эниричеры, чтобы получить дополнительную инфу об источнике сообщений. Всё это было сделано не по прихоти разработчиков, а исходя из реальных потребностей.
И вот уже переехать на другой логгер будет сложно. Либо убиваться и расширять адаптер, но очевидно что задача не очень благодарная.

Знаете, у меня вот под рукой система, в которой внутри серилог, а снаружи абстракция, которая про серилог не знает. И оно вполне себе нормально работает.


А с появлением Microsoft.Extensions.Logging это и вовсе пустой вопрос, потому что он и представляет собой нужную абстракцию.

Ну так не надо широко использовать адаптеры, написанные за час.

Это да, но, как тут уже упомянули, с появлением Microsoft.Extensions.Logging проблема уже решена из коробки.


Просто в давние-давние времена когда решили проекты перетащить на NLog (половина была на нем, а половина еще на log4net) то как раз из-за кастомного адаптера (Microsoft.Extensions.Logging тогда еще и в планах самого MS не было) это практически не стоило никаких усилий.

Only those users with full accounts are able to leave comments. Log in, please.