[WIP] lib: added logger api in node core

[mertcanaltin]

for: #49296 (comment)

I try a draft development for new logger api, and i try create some benchmark for pino and node:logger package

[nodejs-github-bot]

Review requested:

• @nodejs/performance

[Qard]

Rather than passing the handler directly in like this, it would be worth considering a design more like swift-log where there is a separate interface for indirectly attaching a consumer. That way it doesn't need to be the responsibility of each place a logger is constructed to decide where the logs are being shipped. I had planned on working on structured logging myself at some point, using diagnostics_channel to manage dispatching log events to consumers, and even support multiple consumers. In a lot of apps you might want console output but also to be writing logs to other places like log search services.

My original plan was to have separate channels for each log level, that way events of log levels not being listened to could be ignored entirely, but also it would enable each consumer to decide their own log level independently--a console logger might want to only listen to info+ levels while an attached diagnostics tool might want to see everything.

[mertcanaltin]

+1 sound good, thanks for detail, I will apply this plan.

[mertcanaltin]

thats my first performance results:

I think need improvement for child logger area, but ı'm so happy because other results it looks nice.
cc @mcollina @Qard @trentm @jsumners

node:logger vs pino

➜ node git:(mert/create-logger-api/node-core) ✗ ./node benchmark/logger/vs-pino.js n=100000
logger/vs-pino.js scenario="simple" logger="node-logger" n=100000: 5,240,540.823813018
logger/vs-pino.js scenario="child" logger="node-logger" n=100000: 2,635,847.7027229806
logger/vs-pino.js scenario="disabled" logger="node-logger" n=100000: 159,436,487.67795104
logger/vs-pino.js scenario="fields" logger="node-logger" n=100000: 3,619,336.304205216
logger/vs-pino.js scenario="simple" logger="pino" n=100000: 3,398,489.9761368227
logger/vs-pino.js scenario="child" logger="pino" n=100000: 4,489,799.803418606
logger/vs-pino.js scenario="disabled" logger="pino" n=100000: 119,772,384.56038144
logger/vs-pino.js scenario="fields" logger="pino" n=100000: 1,257,930.8609750536

[AugustinMauroy]

IMO we shouldn't expose this kind of API. now we didn't have this style of API

[mertcanaltin]

Good catch!, I will inspect other api for example

[mertcanaltin]

I reviewed other core modules like http, net, and fs - they all expose create* factory functions alongside their classes. Our current implementation follows the same pattern: Logger class is the primary API, with createLogger() as a convenience method (similar to http.createServer()).

[AugustinMauroy]

oh you had right

[mertcanaltin]

IMO we shouldn't expose this kind of API. now we didn't have this style of API

thank you for bringing this to my attention. I've learned something new.

[mertcanaltin]

oh you had right

you to 🙏

[mertcanaltin]

I now learn this feat in Pino

pinojs/pino#2281

I will try add in node:logger