2018-10-22 12:56:14 +00:00
|
|
|
const utils = require('./utils');
|
|
|
|
|
|
|
|
// define max number of logs to keep in memory for this process
|
|
|
|
// to prevent runaway memory leak
|
|
|
|
const MAX_LOGS = require('../constants').logs.maxLogLength;
|
|
|
|
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
/**
|
|
|
|
* Serves as a central point of log handling.
|
|
|
|
*/
|
2018-10-22 12:56:14 +00:00
|
|
|
class LogHandler {
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {Object} options Options object containing:
|
|
|
|
* - {EventEmitter} events Embark events
|
|
|
|
* - {Logger} logger Embark logger
|
|
|
|
* - {String} processName Name of the process for which it's logs
|
|
|
|
* are being handled.
|
|
|
|
* - {Boolean} silent If true, does not log the message, unless
|
|
|
|
* it has a logLevel of 'error'.
|
|
|
|
*/
|
2018-10-22 12:56:14 +00:00
|
|
|
constructor({events, logger, processName, silent}) {
|
|
|
|
this.events = events;
|
|
|
|
this.logger = logger;
|
|
|
|
this.processName = processName;
|
|
|
|
this.silent = silent;
|
|
|
|
|
|
|
|
this.logs = [];
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
this.id = 0;
|
2018-10-22 12:56:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
* Servers as an interception of logs, normalises the message output, adds
|
|
|
|
* metadata (timestamp, id), stores the log in memory, then sends it to the
|
|
|
|
* logger for output. Max number of logs stored in memory is capped by MAX_LOGS.
|
|
|
|
*
|
2018-10-22 12:56:14 +00:00
|
|
|
* @param {Object} msg Object containing the log message (msg.message)
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
* @param {Boolean} alreadyLogged (optional, default = false) If true, prevents
|
|
|
|
* the logger from logging the event. Generally used when the log has already
|
|
|
|
* been logged using the Logger (which emits a "log" event), and is then sent
|
|
|
|
* to `handleLog` for normalization. If allowed to log again, another event
|
|
|
|
* would be emitted, and an infinite loop would occur. Setting to true will
|
|
|
|
* prevent infinite looping.
|
2018-10-22 12:56:14 +00:00
|
|
|
*
|
|
|
|
* @returns {void}
|
|
|
|
*/
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
handleLog(msg, alreadyLogged = false) {
|
|
|
|
if (!msg) return;
|
2018-10-22 12:56:14 +00:00
|
|
|
|
|
|
|
// Sometimes messages come in with line breaks, so we need to break them up accordingly.
|
|
|
|
let processedMessages = [];
|
|
|
|
|
|
|
|
// Ensure that `msg.message` is an array, so we process this consistently. Sometimes it
|
|
|
|
// is an Array, sometimes it is a string.
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
if (typeof msg.message === 'string') {
|
2018-10-22 12:56:14 +00:00
|
|
|
processedMessages = [msg.message];
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
} else if (Array.isArray(msg.message)) {
|
2018-10-22 12:56:14 +00:00
|
|
|
msg.message.forEach(message => {
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
if (Array.isArray(message)) message = message.join('\n');
|
2018-10-22 12:56:14 +00:00
|
|
|
let lines = message.split("\n");
|
|
|
|
lines.forEach(line => processedMessages.push(line));
|
|
|
|
});
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
} else if (typeof msg.message === 'object') {
|
|
|
|
processedMessages.push(JSON.stringify(msg.message));
|
2018-10-22 12:56:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const timestamp = new Date().getTime();
|
|
|
|
|
|
|
|
processedMessages.forEach((message) => {
|
|
|
|
const log = {
|
|
|
|
msg: message,
|
|
|
|
msg_clear: message.stripColors,
|
|
|
|
logLevel: msg.logLevel,
|
|
|
|
name: this.processName,
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
timestamp,
|
|
|
|
id: ++this.id
|
2018-10-22 12:56:14 +00:00
|
|
|
};
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
if (this.logs.length >= MAX_LOGS) {
|
2018-10-22 12:56:14 +00:00
|
|
|
this.logs.shift();
|
|
|
|
}
|
Process logs API refactor
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
2018-10-24 05:54:09 +00:00
|
|
|
this.logs.push(log);
|
|
|
|
this.events.emit(`process-log-${this.processName}`, log);
|
|
|
|
if ((this.silent && msg.type !== 'error') || alreadyLogged) {
|
2018-10-22 12:56:14 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (this.logger[msg.type]) {
|
|
|
|
return this.logger[msg.type](utils.normalizeInput(message));
|
|
|
|
}
|
|
|
|
this.logger.debug(utils.normalizeInput(message));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
module.exports = LogHandler;
|