A lightweight component for gathering and emitting application logs

It's designed with low development and runtime cost in mind, encouraging usage with minimum concern for overhead. Runtime monitoring can be as chatty as desired, outputting every log statement of every type, or finely tuned with regular expressions to monitor specific log statements.

Log Collector

As a collector, it's a place to send application logs.

Example for outputting a log in your application:

var log = require('monitor').getLogger('myModule');
...
log.info('Credit limit accepted', limit, requestedAmount);

The above is a request to output an info log for myModule named Credit limit accepted. The log entry includes all additional parameters, in this case the customer credit limit and the reqeusted amount.

The full name for this log entry is: "info.myModule.Credit limit accepted" The name is important, as monitors can be configured to output logs based on this name.

Best practices are to include dynamic parameters in extra arguments vs. concatenating strings. This reduces logging overhead, especially for log statements that aren't currently being watched.

Log Emitter

As an emitter, the Log module is a place to capture logging output.

When listening for log entries, wildcards can be used to register for particular log types and entries.

var Log = require('monitor').Log;
...
Log.on('info.myModule.*', myFunction);

Will call myFunction when all info.myModule.* logs are emitted.

Listeners are invoked with the following arguments:

• type - The log type (trace, debug, info, warn, error, or fatal)
• module - The logger module name
• name - The log entry name
• args... - Additional arguments passed into the log entry are passed on as additional args to the event listener.

Wildcards

A flexible and user-oriented wildcard pattern is used for monitoring logs. The pattern is described in the Wildcard secttion of the Stats class.

Choosing Good Names

It's a good idea to pick a good naming scheme with each dot-delimited segment having a consistent, well-defined purpose. Volatile segments should be as deep into the hierarchy (furthest right) as possible. Keeping the names less volatile makes it easier to turn statistics recording on for all logs.