0.1.2 • Published 4 years ago

isnode-mod-logger v0.1.2

Weekly downloads
27
License
-
Repository
github
Last release
4 years ago

ISNode Logger Module

Introduction

This is just a module for the ISNode Framework. To learn how to use the framework, we strongly suggest obtaining a copy of the Hello World example.

The logger module is responsible for handling all logging from the core application server, it's module dependencies and services loaded in to the server. It is built in an extensible fashion - where additional log "sinks" can be added to the module as it is further developed.

The current version of the logger module supports two log sinks - STDOUT (default) and file-based logging. Configuration of the logging module (including which log levels to expose and which sinks to activate) exists within the app server config.json file, within the "logger" object (in root of config.json).

Methods

log(level,logMsg,attrObj)

Synchronous Function. Logs a message to all configured log sinks.

Input Parameters:

  1. level - (String) The log level. Available options are - "startup", "shutdown", "debug", "warning", "error" and "fatal"
  2. logMsg - (String) The free text message that is to be logged. Eg; "System is starting up..."
  3. attrObj - (Object) Optional. A JSON object containing any additional data to include in to the log. The current version of the logger module does not pass this additional data to any of the existing sinks

Returns: This method does not return anything.

Code example

// The below use case assumes that you have an instance of the isnode master object

var log = isnode.module("logger").log;
log("debug", "Instantiating the Data Module");

/* 
  If STDOUT (or console) is configured as a log sink, it would be expected that a new line would be printed to STDOUT (visible within the console/terminal) that looks something like - "2019-04-06T05:57:57.930Z (debug) Instantiating the Data Module"
*/

Configuration Example

/*
	Within the below example:
	1. "logger.enabled" must be set to true for any logged messages to be passed to any activated sinks
	2. "logger.output" contains a series of attribute-value pairs representing each log level that should be passed to the sinks. Ie; in the below example the log level of "startup" is defined and would thus be passed to all activated sinks
  3. "logger.logMetadataObjects", if set to "true" will dump the JSON object that was attached to a log entry to all sinks directly after the log message. This may be an error object, stack trace or similar. This should really only be set to "true" for debugging purposes.
	4. "logger.sinks" contains a series of sink objects - each representing an available sink.
	5. Each sink object has a parameter (eg; "console") that represents a supported sink. Unsupported sinks are ignored
	6. Each sink object (at a minimum) has an "enabled" attribute that allows you to enable/disable each sink, irregardless of whether the logger module is enabled. Ie; for a message to be passed to a sink - "logger.enabled" must equal true AND "sinks.file.enabled" (as an example) must also equal true. If "logger.enabled" is true, but only some sinks are enabled - only those sinks that are enabled will receive log messages.
	7. Some sinks (like file) have custom attributes. For example - you can define "file.location", setting it to the path+file that you want to log to. In this use case - if "file.location" is not provided, it will default to "./logs/isnode.log" (in the root of the application server folder)
*/

{
  "logger": {
    "enabled": true,
    "output": ["startup","shutdown","debug","warning","error","fatal"],
    "logMetadataObjects": false,
    "sinks": {
      "console": {"enabled": true},
      "file": {
        "enabled": true,
        "location": "./logs/isnode.log"
      }
    }
  }
}

0.1.2

4 years ago

0.1.1

4 years ago

0.1.0

5 years ago

0.0.9

5 years ago

0.0.8

5 years ago

0.0.6

5 years ago

0.0.5

5 years ago

0.0.1

6 years ago