Logging is important for debugging and auditing applications. StrongLoop provides several options for logging:
- Basic logging using the Node
slc ctl log-dumpcommand 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.
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
stderrand 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:
--follow option to continuously dump the logs to the the console:
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.