Logging

Framework uses winston logger as a main subsystem to logging

You can adjust different transports (console and sentry available by default) and add you own transport with own parameters

Frameworks provides basic initialization of Winston so you can easily use it from out of the box, but you still have ability to adjust it as you want

Logging levels

RFC5424 defines a logger level. More higher levels will include messages from the lower level. In other word if you set ‘warn’ level then logger will report ‘error’ as well, but will not report debug level

You can read more about levels on winston levels documentation

But in short that default levels

{ 
  error: 0, 
  warn: 1, 
  info: 2, 
  http: 3,
  verbose: 4, 
  debug: 5, 
  silly: 6 
}

API

Each class have access to logger instance via

this.logger

this.logger.error('error message');
this.logger.warn('warn message');
this.logger.info('info message');
this.logger.http('http message');
this.logger.verbose('verbose message');
this.logger.debug('debug message');
this.logger.silly('silly message');

tip

Please note that this.logger is an instance of winston.logger and you can use any methods from it

Default transports

By default the framework provides two transports: console and sentry (via (winston-transport-sentry-node)[https://github.com/aandrewww/winston-transport-sentry-node]).

Configuration

We try to keep configuration simple and powerful - you able to enable/disable loggers and adding own with pass all available options to transport

Configuration files located on ‘config/log.js’

export default {
  transports: [
    {
      transport: 'winston-transport-sentry-node', // transport name (npm package name)
      transportOptions: { // options that will pass info transport instance 
        sentry: {
          dsn: process.env.LOGGER_SENTRY_DSN,
        },
        level: process.env.LOGGER_SENTRY_LEVEL || 'info',
      },
      enable: process.env.LOGGER_SENTRY_ENABLE || false, // is transport enabled on not
    },
    {
        // ....
    },
    /// more transports
  ],
};

Config contains a “transports” array. Each transport can be included in the logger.

Transport name it’s a npm package name that framework will be required. You can use any transport from NPM

Field transportOptions it’s transport options - you can pass any options here for transport. Please refer to transport documentation

And finally field enable will enable/disable modules for logger. You can check “NODE_ENV” on config documentation to least more how you can use it depend on you environment

Add own transport

Adding own transport is simple process.

npm i ${WINSTON_TRANSPORT_PACKAGE}

Then add it into ‘config/log.js’ config file

export default {
  transports: [
    {
        // .....
        // some already existed transports
    }, 
    {
        // ....
    },
    {
      transport: 'WINSTON_TRANSPORT_PACKAGE',
      transportOptions: { // options that will pass info transport instance 
        // .... you transport options
      },
      enable: true
    },
  ],
};

tip

Feel free to use environment variables on your transport config as well. That simplify working with multiple environments

Console output for logger

Console loggers act in a customized way to provide more verbose info. Default console output constructed as

(${process.pid}) ${info.label} ${info.timestamp} ${info.level} : ${info.message}

Where “process.pid” - pid of node process. Useful in cluster environment “info.label” - label of place. More info below “info.timestamp” - date of event “info.level” - log level (“error”,”warn”, etc) “Info.message” - message that passed to logger (eg: this.logger.info(“this is a message”);

info.label

Inside the base class we have a method “loggerGroup”that is used as a first part of info message generation. This useful to group messages like “controllers”,”models”, etc

Framework uses: “command”, “connector”, “controller”, “model” and “CLI_” groups.

tip

Feel free to introduce your own groups

Second part is generated by the base class function “getConstructorName” that by default grabs the constructor name and adds it to the info string. You can overwrite this method for you classes

Example

(15950)  [modelCoin]  2021-10-18T11:17:54.746Z  verbose : Model have no hooks

Here:

(15950) - process pid 
[modelCoin] -  info message ("model" - group. "Coin" model name)
2021-10-18T11:17:54.746Z - time
verbose - level 
Model have no hooks - message 

Environment variables

Sentry transport

LOGGER_SENTRY_DSN sentry DSN

LOGGER_SENTRY_LEVEL logs level that shouls go into sentry. Default 'info'

LOGGER_SENTRY_ENABLE enable or not sentry logger. Default 'false'

Console transport

LOGGER_CONSOLE_LEVEL logs level. Default 'silly' (include all)

LOGGER_CONSOLE_ENABLE enable or not console logger. Default 'true'