Feature request: create child logger we prebound meta data

[nickcarenza]

I would like to create a child logger with some prebound meta data. I pass around the logger to different parts of my applications and find it very convenient to bind some information about that process just once.

[parthgandhi7]

yes. something like this is needed. +1

[ORusak]

+1

[FastNinja]

there is a serious need for that. For example - in any API web serviceyou want to log request ID along with log message. But you don't want to pass this information to your objects - all you want to pass is a child logger.
There are projects that are trying to close that gap - but looks they are a bit outdated/not used and they don't work with logging exceptions:
https://github.com/citrix-research/node-winston-context

[felimartina]

I have the same problem!
Anyone knows at least a work around for this?
Probably creating a custom formatter like the following (haven't tried...just brain storming)
FYI...I need it for json logging

    var fixedMetas = {appName: 'APP_1'} // Example of a fixed meta
formatter(params) {
        // It's general properties are: timestamp, level, message, meta.
        var meta = params.meta || {};
        for (var metaKey in fixedMetas) {
            meta[metaKey] = fixedMetas[key];
        }
        const meta = params.meta !== undefined ? util.inspect(params.meta, { depth: null }) : '';
        return params
      },

Any thoughts?

[FastNinja]

Just use winston-context ( search in npm packages ). It allows you to create a child logger with bound context ( custom metadata ). We use it to log API calls- each call will have a unique ID . That ID will be used for al log messages that are created during one API call.

[sinedied]

Still no love for this one? This seems a pretty basic need other loggers implements since ages :/

[gswalden]

Second 👍 for winston-context

[sinedied]

winston-context is outdated does not solves the issue problem, it's more of a hack than a real solution.

It's really a "standard" feature for loggers, I really wonder how it got missed out in the design...
node-bunyan had this since the beginning, and if it wasn't for the json output I would have switched already 😕

[bertho-zero]

+1

[GGYaX]

+1

[antoniusostermann]

+1

[birbird]

+1

[kibertoad]

@indexzero I am thinking about picking this one up, could you share some of your design vision how this could look within existing architecture and where the appropriate code should go?

[indexzero]

Fixed in #1471. Will be released in winston@3.2.0. Follow the remaining items for that release here.