NOTE
StrongLoop Arc and slc are no longer under active development, and will soon be deprecated. Arc's features are being included in the IBM API Connect Developer Toolkit: Please use it instead.
Skip to end of metadata
Go to start of metadata

Overview

Logging is important for debugging and auditing applications.  StrongLoop provides several options for logging:

  • Basic logging using the Node console.log() function.
  • Using slc ctl log-dump command to dump the last 1 MByte of log file content .
  • Logging with third-party libraries such as Winston and Bunyan.

In production, when an application is running under control of the StrongLoop PM service, logging is controlled by Upstart or Systemd.

Best practices

To create effective application logs, follow these guidelines:

  • Ensure that logs contain a timestamp and process ID from the process that generated the event.
  • Log one event per line.
  • Log as much as possible within reason.
  • Leave log-level-based filtering to the external log processor/viewer.
  • Leave aggregation of logs to the supervisor process.
  • If logging to a file, just log to stdout or stderr and leave the file management to the supervisor process.

The StrongLoop command-line tool slc simplifies logging by taking care of some of the concerns for you.

Logging to the console

The simplest way to do logging is to use the standard console.log() function that prints logs to stdout or stderr; for example:

You can also use printf-style formating options; for example:

For more information on console.log(), see the Node.js documentation.

Logging for a local application

Run a local application named my-app under control of StrongLoop Process Manager:

Then, you can dump the last 1 MByte of log file content to the console with this command:

Use the --follow option to continuously dump the logs to the the console:

Icon

 The slc ctl log-dump command actually consumes the log messages, so if more than one person calls it for one application, only one of them will see the logs.

Logging in production

Follow the instructions in Setting up a production host to install and run StrongLoop PM as a service.  Logging behavior then depends on the operating system (whether you're using Upstart or systemd).

With Upstart 0.6, logs go to syslog so that syslog can handle log rotation, which means you have to configure syslog to redirect log entries if you want them rotated.

 
With Upstart 1.4, log rotation and direction is handled by Upstart itself and logs are saved to /var/log/upstart/strong-pm.log.

Everything run under systemd is logged to journald, which is accessible through the journalctl command. See the journalctl man page for more information about journalctl. For convenience, StrongLoop systemd service definitions also log to syslog.