Creating your own Logger  Copy Section

You get started by creating a logger using winston.createLogger:

A logger accepts the following parameters:
| Name          | Default                     |  Description    |
| ------------- | --------------------------- | --------------- |
| level       | 'info'                    | Log only if info.level is less than or equal to this level  |
| levels      | winston.config.npm.levels | Levels (and colors) representing log priorities            |
| format      | winston.format.json       | Formatting for info messages  (see: [Formats])           |
| transports  | [] _(No transports)_      | Set of logging targets for info messages                 |
| exitOnError | true                      | If false, handled exceptions will not cause process.exit |
| silent      | false                     | If true, all logs are suppressed |
The levels provided to createLogger will be defined as convenience methods
on the logger returned.

You can add or remove transports from the logger once it has been provided
to you from winston.createLogger:

You can also wholesale reconfigure a winston.Logger instance using the
configure method:

Creating child loggers  Copy Section
You can create child loggers from existing loggers to pass metadata overrides:

.child is likely to be bugged if you're also extending the Logger class, due to some implementation details that make this keyword to point to unexpected things. Use with caution.
Streams, objectMode, and info objects , and info objects')" title="Copy section prompt for LLMs"> Copy Section
In winston, both Logger and Transport instances are treated as
objectMode
streams that accept an info object.
The info parameter provided to a given format represents a single log
message. The object itself is mutable. Every info must have at least the
level and message properties:

Properties besides level and message are considered as "meta". i.e.:

Several of the formats in logform itself add additional properties:
| Property    | Format added by | Description |
| ----------- | --------------- | ----------- |
| splat     | splat()       | String interpolation splat for %d %s-style messages. |
| timestamp | timestamp()   |  timestamp the message was received. |
| label     | label()       | Custom label associated with each message. |
| ms        | ms()          | Number of milliseconds since the previous log message. |
As a consumer you may add whatever properties you wish – _internal state is
maintained by Symbol properties:_
- Symbol.for('level') _(READ-ONLY):_ equal to level property.
  Is treated as immutable by all code.
- Symbol.for('message'): complete string message set by "finalizing formats":
  - json
  - logstash
  - printf
  - prettyPrint
  - simple
- Symbol.for('splat'): additional string interpolation arguments. _Used
  exclusively by splat() format._
These Symbols are stored in another package: triple-beam so that all
consumers of logform can have the same Symbol reference. i.e.:

NOTE: any { message } property in a meta object provided will

automatically be concatenated to any msg already provided: For

example the below will concatenate 'world' onto 'hello':

>

String interpolation  Copy Section
The log method provides the string interpolation using [util.format]. It
must be enabled using format.splat().
Below is an example that defines a format with string interpolation of
messages using format.splat and then serializes the entire info message
using format.simple.

Filtering info Objects  Objects')" title="Copy section prompt for LLMs"> Copy Section
If you wish to filter out a given info Object completely when logging then
simply return a falsey value.

Use of format.combine will respect any falsey values return and stop
evaluation of later formats in the series. For example:

Creating custom formats  Copy Section
Formats are prototypal objects (i.e. class instances) that define a single
method: transform(info, opts) and return the mutated info:
- info: an object representing the log message.
- opts: setting specific to the current instance of the format.
They are expected to return one of two things:
- An info Object representing the modified info argument. Object
references need not be preserved if immutability is preferred. All current
built-in formats consider info mutable, but [immutablejs] is being
considered for future releases.
- A falsey value indicating that the info argument should be ignored by the
caller. (See: Filtering info Objects) below.
winston.format is designed to be as simple as possible. To define a new
format, simply pass it a transform(info, opts) function to get a new
Format.
The named Format returned can be used to create as many copies of the given
Format as desired:

Similarly, npm logging levels are prioritized from 0 to 6 (highest to
lowest):

If you do not explicitly define the levels that winston should use, the
npm levels above will be used.
Using Logging Levels  Copy Section
Setting the level for your logging message can be accomplished in one of two
ways. You can pass a string representing the logging level to the log() method
or use the level specified methods defined on every winston Logger.

winston allows you to define a level property on each transport which
specifies the maximum level of messages that a transport should log. For
example, using the syslog levels you could log only error messages to the
console and everything info and below to a file (which includes error
messages):

You may also dynamically change the log level of a transport:

winston supports customizable logging levels, defaulting to npm style
logging levels. Levels must be specified at the time of creating your logger.
Using Custom Logging Levels  Copy Section
In addition to the predefined npm, syslog, and cli levels available in
winston, you can also choose to define your own:

Although there is slight repetition in this data structure, it enables simple
encapsulation if you do not want to have colors. If you do wish to have
colors, in addition to passing the levels to the Logger itself, you must make
winston aware of them:

This enables loggers using the colorize formatter to appropriately color and style
the output of custom levels.
Additionally, you can also change background color and font style.
For example,

Possible options are below.
* Font styles: bold, dim, italic, underline, inverse, hidden,
  strikethrough.
* Font foreground colors: black, red, green, yellow, blue, magenta,
  cyan, white, gray, grey.
* Background colors: blackBG, redBG, greenBG, yellowBG, blueBG
  magentaBG, cyanBG, whiteBG
Colorizing Standard logging levels  Copy Section
To colorize the standard logging level add

where winston.format.simple() is whatever other formatter you want to use.  The colorize formatter must come before any formatters adding text you wish to color.
Colorizing full log line when json formatting logs  Copy Section
To colorize the full log line with the json formatter you can apply the following

Transports  Copy Chapter
There are several [core transports] included in  winston, which leverage the
built-in networking and file I/O offered by Node.js core. In addition, there
are [additional transports] written by members of the community.
Multiple transports of the same type  Copy Chapter
It is possible to use multiple transports of the same type e.g.
winston.transports.File when you construct the transport.

If you later want to remove one of these transports you can do so by using the
transport itself. e.g.:

Adding Custom Transports  Copy Chapter
Adding a custom transport is easy. All you need to do is accept any options
you need, implement a log() method, and consume it with winston.

Exceptions  Copy Chapter
Handling Uncaught Exceptions with winston  Copy Section
With winston, it is possible to catch and log uncaughtException events
from your process. With your own logger instance you can enable this behavior
when it's created or later on in your applications lifecycle:

When working with custom logger instances, you can pass in separate transports
to the exceptionHandlers property or set handleExceptions on any
transport.
##### Example 1

##### Example 2

The exitOnError option can also be a function to prevent exit on only
certain types of errors:

Rejections  Copy Chapter
Handling Uncaught Promise Rejections with winston  Copy Section
With winston, it is possible to catch and log unhandledRejection events
from your process. With your own logger instance you can enable this behavior
when it's created or later on in your applications lifecycle:

Also you can start a timer and keep a reference that you can call .done()
on:

All profile messages are set to 'info' level by default, and both message and
metadata are optional.  For individual profile messages, you can override the default log level by supplying a metadata object with a level property:

Querying Logs  Copy Chapter
winston supports querying of logs with Loggly-like options. See Loggly
Search API. Specifically:
File, Couchdb, Redis, Loggly, Nssocket, and Http.

Streaming Logs  Copy Chapter

Streaming allows you to stream your logs back from your chosen transport.

Further Reading  Copy Chapter
Using the Default Logger  Copy Section
The default logger is accessible through the winston module directly. Any
method that you could call on an instance of a logger is available on the
default logger:

By default, no transports are set on the default logger. You must
add or remove transports via the add() and remove() methods:

Or do it with one call to configure():

For more documentation about working with each individual transport supported
by winston see the winston Transports document.
Awaiting logs to be written in winston ')" title="Copy section prompt for LLMs"> Copy Section
Often it is useful to wait for your logs to be written before exiting the
process. Each instance of winston.Logger is also a [Node.js stream]. A
finish event will be raised when all logs have flushed to all transports
after the stream has been ended.

Working with multiple Loggers in winston  Copy Section
Often in larger, more complex, applications it is necessary to have multiple
logger instances with different settings. Each logger is responsible for a
different feature area (or category). This is exposed in winston in two
ways: through winston.loggers and instances of winston.Container. In fact,
winston.loggers is just a predefined instance of winston.Container:

If you prefer to manage the Container yourself, you can simply instantiate one:

Routing Console transport messages to the console instead of stdout and stderr  Copy Section
By default the winston.transports.Console transport sends messages to stdout and stderr. This
is fine in most situations; however, there are some cases where this isn't desirable, including:
- Debugging using VSCode and attaching to, rather than launching, a Node.js process
- Writing JSON format messages in AWS Lambda
- Logging during Jest tests with the --silent option
To make the transport log use console.log(), console.warn() and console.error()
instead, set the forceConsole option to true:

Installation  Copy Chapter

Run Tests  Copy Chapter