Winston: 'debug' level is getting directed to stderr instead of stdout

Created on 23 Sep 2016  路  8Comments  路  Source: winstonjs/winston

Setup

  • winston version 2.2.0
  • node version 4.4.7

    Repro Steps

  1. Save the following into a file named app.js:

    ``` #!javascript
    'use strict';

    const winston = require('winston');
    const log = new winston.Logger({
    levels: {
    error: 3,
    warning: 4,
    notice: 5,
    info: 6,
    debug: 7,
    },
    transports: [
    new (winston.transports.Console)({
    level: 'debug',
    }),
    ],
    });

    log.error('test error');
    log.warning('test warning');
    log.notice('test notice');
    log.info('test info');
    log.debug('test debug');
    ```

  2. Run the app with command: node app.js > app.log 2>err.log
  3. View the contents of err.log and notice that the log.error and log.debug output both ended up in there (former expected, latter not expected). View the contents of app.log and notice that the log.warning, log.notice, and log.info output all ended up in there (as expected).
  4. Edit app.js to find/replace all 4 instances of 'debug' with any other word - e.g. 'debugz'.
  5. Run the app (again) with (the same) command: node app.js > app.log 2>err.log
  6. Notice how all the stuff ends up in the same file, _except_ that the log.debugz output is now in app.log and _not_ in err.log.

Most helpful comment

Found the answer here:
https://github.com/winstonjs/winston/blob/master/docs/transports.md

... i.e. setting the levels to log to stderr instead of stdout via stderrLevels transport option.

FWIW, I didn't find it very intuitive that this option would default to ['error', 'debug'], but that may be based on my own ignorance of how that default would make sense.

I'll let someone on the project close this issue after reading this feedback, but I need no additional help.

All 8 comments

just found related issue #556 ... still trying to understand it, but wanted to get that out there before anyone wastes too much time investigating / responding

Found the answer here:
https://github.com/winstonjs/winston/blob/master/docs/transports.md

... i.e. setting the levels to log to stderr instead of stdout via stderrLevels transport option.

FWIW, I didn't find it very intuitive that this option would default to ['error', 'debug'], but that may be based on my own ignorance of how that default would make sense.

I'll let someone on the project close this issue after reading this feedback, but I need no additional help.

Debug logging does not indicate an error in my eyes. Good that it can be changed via stderrLevels, but shouldn't the default be ['error'] in stead of ['error', 'debug']?

Maybe I can see the sense of it, although I do not agree with it.

It might make sense under the following terms:

  • you use one main transport that does not go to the console (e.g file, sql, loglly)

In this case, you'll have to search for your debug notices in the file/sql/loglly,
while stderr emits it to your console.

IMHO - It's a kinda twisted gotcha. I'm here just because I ran into it myself, and decided to share my observation.

It's of the kind of settings that are fit to development time, and nowhere else.
IMHO - this behavior should not the default, but enabled by the user.

I agree that this is a very strange default setting.

I'm building a system that runs commands locally, and it also runs its own commands over SSH in child processes too. And have been investigating why the local commands appeared to work (I'm not monitoring STDERR on the main local node process), but the same remote SSH commands were producing STDERR output (I'm throwing local exceptions when the child process's remote command has STDERR output).

First I thought it was something to do with SSH itself handling output differently until I ran further tests to rule SSH out, and after a while thought to look into Winston.

Thanks for posting this issue. This would have taken me a while longer to figure out otherwise.

Duplicate of #1024, which will remain open.

The feature has existed for a long time, but if enough folks are not happy with it then we can remove it as a breaking change in [email protected]

I think you should let the user decide.
maybe a setting console appender / transport.

+1 for leaving debug out of stderr.

Was this page helpful?
5 / 5 - 1 ratings