reactioncommerce/logger

Name: logger

Owner: Reaction Commerce

Description: Reaction Commerce application logging API.

Created: 2018-03-30 18:08:38.0

Updated: 2018-04-04 13:56:18.0

Pushed: 2018-04-15 09:19:03.0

Homepage: null

Size: 84

Language: JavaScript

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

reaction-logger

Reaction uses the Bunyan logging library to provide a stream capable log handler that can send your logs to a variety of places. By default, the Reaction logger outputs to the console (stdout), but you can also stream your server side logs to services like Loggly (see below) or even save them to your database.

Log Level

Most loggers have the concept of log level. That allows you to filter what is visible in your logs (see available levels and their descriptions below). The default levels in Reaction are INFO on the server and WARN on the client. To override the log level on the server, you can modify REACTION_LOG_LEVEL environment variable. Overriding the log level on the client requires using the settings.json approach - specifically in the public object (see below).

Environment Variables

To set the logger name that appears at the beginning of every log line and as the name key in the raw JSON output, you can set…

fault: Reaction
rt REACTION_LOGGER_NAME="My Custom Logger"

The default log level is INFO. You can override that with REACTION_LOG_LEVEL (see more about available levels below).

To set the server log level in development, you can add the environment variable before the reaction command when starting the app.

TION_LOG_LEVEL="DEBUG" reaction

Or export it first…

rt REACTION_LOG_LEVEL="DEBUG"

tion

To set it in production (assuming you're using Docker), it would look like this:

er run -e REACTION_LOG_LEVEL="DEBUG" ...

Log Levels

When doing custom development and adding more logging to the app, we suggest following the Bunyan recommendations on log levels and use appropriate levels for your messages.

The log levels in Bunyan are as follows. The level descriptions are best practice opinions.

• “TRACE” (10): Logging from external libraries used by your app or very detailed application logging.
• “DEBUG” (20): Anything too verbose to be included in the standard “info” level.
• “INFO” (30): Detail on regular operation.
• “WARN” (40): Detail on something that should probably be looked at by an operator eventually.
• “ERROR” (50): Fatal for a particular event, but the service/app continues servicing other events. An operator should look at this soon.
• “FATAL” (60): The service/app is going to stop or become unusable now. An operator should definitely look into this soon.

Suggestions: Use “DEBUG” sparingly. Information that will be useful to debug errors post mortem should usually be included in “info” messages if it's generally relevant or else with the corresponding “error” event. Don't rely on spewing mostly irrelevant debug messages all the time and sifting through them when an error occurs.

Usage

rt Logger from "@reactioncommerce/logger";


ogging general info


 general message string
er.info("Something important happened!");

nclude some event-specific data in the message string
er.info(`Order ID ${order._id} has been submitted by user ${order.userId}`);

r extend the JSON output of the logger with an object
note that the object should go before the message text)
er.info({ order }, "Order has been submitted");



ogging warnings


og a non-critical warning that should be investigated
er.warn("API key missing. The feature won't work.");



ogging errors


er.error("Something went wrong!");

unyan has an error object parser built in, so you can pass
rrors into the logger and it will format them in your console
s well as extend the raw JSON log output if you are piping
our logs to another service like Loggly.
note that the error object should go before the message text)
mething((err, result) => {
 (err) {
Logger.error(err, "Something went wrong!");
throw err;

gger.info("That thing worked!");
 or
gger.info({ result }, "That thing worked!");




ogging fatal events


f an event is considered fatal (will stop the app from functioning
ntirely), you should use the FATAL log level.
ote that this will rarely be needed.  Most negative events
re just warnings or errors and don't entirely prevent the
pp from running.
er.fatal("The app is going to crash now! Attention needed!");

Outputs

As mentioned above, Bunyan is capable of sending your logs to a variety of services or you can even build your own plugin to send the raw JSON output to any API you choose. We suggest searching npm for Bunyan to see what options are already available before attempting to build your own. There are already a lot to choose from.

By default, Reaction sends logs to the console, but we also support sending to Loggly.

Loggly

Default level: DEBUG

Environment variables

quired
LY_SUBDOMAIN=""
LY_TOKEN=""

tional
LY_LOG_LEVEL=""