Some of the basic requirements to have a custom logger are following:

• To store log messages based on their level of importance in a file.
• To create a structure in log messages which can be easily parsed and utilised in upward services.
• Rotate such a log file on hourly/daily/weekly basis.
• Add datetime stamp with every log message to make it more consumable for decision making while debugging.

SWIK-835 has implemented custom logger (based on Winston logging library) for SlideWiki Platform with basic features and has also provided extended features to help the development and tracking of control flow in SlideWiki Platform. Following are the examples of custom log messages. Similar to that you may see on your development terminal:

Custom logger configuration

Log configuration is provided in ./configs/log.js file which is used by the SlideWiki Platform. When the system is deployed for production, the code in the file ./configs/log_prod_sample.js should be copied to ./configs/log.js . There are two transports (i.e., the storage device where the log message should go) provided for the SlideWiki Platform, first is console (i.e., developer's terminal) and second is file (a rotating file transport is used, i.e., on a defined time period a new file will be created with appropriate date). Both can have different log levels, for example, console can be set to debug level while the file transport is set to warning level.

How to use custom logger

Ideally, every developer on SlideWiki Platform should use custom logger instead of console.log to get following benefits:

• to check if the code is working as intended by using information/warning/error messages at appropriate places in the code. You do not need to worry about removing these messages later on. Just ensure that when you create such messages you are using the appropriate log level (log levels are explained in appropriate detail in RFC5424, PS: Wikipedia link  or RFC5424 link).
• to provide opportunity for other developers to have a standardised record of warnings/errors etc. that he/she can then share with appropriate developer(s) or with the team for analysis and resolution. This is possible by sharing the log file (and mentioning timestamp if necessary).
• to record errors generated on stable platform where no one is actually looking at the console messages. If errors are important/serious in nature, the historical record of log files can be used for analysis and resolution.

To use the custom logger built in SWIK-835, developers should import the following in their respective code blocks (not in react components but can be used in Flux actions, platform services, routes etc). Please ensure that you are providing correct path inside require.

const clog = require('./log/clog');

Then in your code, you can use the custom logger as follows:

// In case of error, in the below code we are also sending metadata such as filepath and err in final log message.
clog.error(context, payload, {filepath: __filename, err: err});


// In case you want to send debug message
clog.debug(context, payload, 'This is my debug message');

Parameters

1. There are three parameters: context, payload and (optional) message.
2. context and payload parameters are used to provide access to request id and navigation stack.
3. message parameter can take a string or a JavaScript object. Treat this as metadata that you want to send in your log message. You can send whatever you want.

Log format

1. id , as it appears in log message is set in server.js. For every new request SlideWiki Platform receives, a new UUID is generated and used as request id.
2. If the developer is using (optional) message parameter for sending metadata then all of those metadata will appear in the log message after the json key message (example: message=filepath:/home/user1/Workspace/slidewiki-platform/actions/loadFeatured.js, err:TypeError: Cannot read property 'update' of undefined)
3. navStack is a sequential control flow that the request took in SlideWiki Platform. Example: navStack=[navigateAction, action, loadDeck, loadContentModules, loadCommentsCount] can be written as: navigateAction → action → loadDeck → loadContentModules → loadCommentsCount.

Custom logger files explained

• For configuration: ./configs/log.js
• For production configuration copy code from ./configs/log_prod_sample.js to ./configs/log.js . This should be done in travis and docker configuration.
• Propagation of log message from developer's code to appropriate transport: ./actions/log/clog.js and ./services/logservice.js
• Log directory: ./logs
• NPM package: Winston and winston-daily-rotate-file