@ksfcore/logs v2.1.1

@ksfcore/logs

Based on winston and winston-ksf, a log component conforming to the KSF framework specification, It contains staining logs, rolling (size, time) logs.

Installation

npm install @ksfcore/logs

Examples

Output rolling log

var logger = new ksfLogs ('KsfRotate');

Output daily log named access

var logger = new ksfLogs ('KsfDate', 'access');

Output daily logs named access, only local and not remote logs

var logger = new ksfLogs ('KsfDate', 'access', {
logTo: ksfLogs.LogTo.Local
});

Output an hourly log named access

var logger = new ksfLogs ('KsfDate', 'access', {
format: ksfLogs.DateFormat.LogByHour
});

Output a 20-minute scroll log named access in the format of 2015-01-01_10: 00

var logger = new ksfLogs ('KsfDate', 'access', {
format: new (ksfLogs.DateFormat.LogByMinute) (20, '% Y-% m-% d_% H:% M')
});

Specify output INFO level log information

logger.info ('data');
logger.info ('data1', 'data2', 'data3');

Specifies that the current INFO level log output needs to be dyed

logger.info ('data', logger.getDyeingObj (true));

Initialization

No need to configure this if the service is running on the KSF platform

If the service is debugged in the local environment, all log types will be output to the Console

Can be initialized by calling the ksfLogs.setConfig (data) static method

data (String | Object) can be a ksf configuration file path or a configured (@ksfcore/utils).Config instance.

use

Instantiation

var ksfLogs = require ('@ ksf / logs');

var logger = new ksfLogs (type, [name, options]);

type (String) log type:

• KsfRotate: Scroll logs by size
• KsfDate: Roll logs by time
• KsfRemote: remote log

name (String) User-defined file name (optional)

options (Object) According to different log types, there are different parameters, but the following parameters are shared by each type:

• hasSufix: whether the log file name has a .log suffix, default is true
• hasAppNamePrefix: Whether to allow the framework to add a business-related identifier to the log file name. The default value is true
• concatStr: The connector between characters in the log file name, The default value is _
• separ: separator between log content items, default is |

For other parameters in options, please refer to the description of different log types.

Under normal circumstances, the same log file should share the same logger, instead of instantiating multiple times

Log output

There are 4 log levels INFO, DEBUG,WARN, and ERROR, which can be output by corresponding methods

logger.info ([data], [...]);
logger.debug ([data], [...]);
logger.warn ([data], [...]);
logger.error ([data], [...]);

The method supports multiple parameters, see util.format () for details.

For dyeing, please see the section Staining

File name and line number

By default, the output log contains filename: line number where the code that calls the output method is located.

The following examples can be customized (for packaging modules) or turned off (to improve performance).

Turn off file name and line number output:

logger.info('data', {
	lineno : false
});

Custom file name and line number output:

logger.info ('data', {
lineno: 'app.js: 123'
});

For more details, please refer to @ksfcore/winston-ksf.Metadata

Log level

The priority of the log level is: INFO <DEBUG <WARN <ERROR <NONE

Among them, except that the default level of KsfRotate is DEBUG, all others areINFO.

If you need to change the log level, you can call the logger.setLevel (level) method and pass in the required log level:

logger.setLevel ('info');
logger.setLevel ('none'); // none is a special log level, all logs are not output

If the service is running on the KSF platform:

• The module will receive the management command of Log Level Change and automatically change the current log level.
• The module reads the ksf.application.server.logLevel section in the KSF configuration file to configure the log level.
• The above two log level configurations are only effective for Rolling logs by size (KsfRotate).

Format of the log content (Formatter)

The module provides two simplified log processing methods: Formatter.Simple () and complex Formatter.Detail ():

• Complicated: date time | PID | log level | file name and line number | content
• Less: datetime | contents

Different log types use different processing methods by default.

For more information on Formatter, please visit @ksfcore/winston-ksf.Formatter

Scroll logs by size (KsfRotate)

When initializing a logger of typeKsfRotate, options also accepts the following parameters:

• maxFiles: maximum total number of files (ie n in the example), default is 10
• maxSize: maximum file size (unit is bytes), default is 10M
• formatter: Define the log content formatting method, The default value is Formatter.Detail ()

For more information on KsfRotate, please visit @ksfcore/winston-ksf.KsfRotate

Time correlation (DateFormat)

Defines the processing method of time-related logs (KsfDate,KsfRemote) scrolling:

• Log by day: LogByDay (interval, pattern)
• Log by 1 hour: LogByHour (interval, pattern)
• Log by 10 minutes: LogByMinute (interval, pattern)
• Custom format log: LogByCustom (pattern)

Among them, "interval" is the log rolling interval, and "pattern" is the format of the time in the log file name

In general, you can use literals directly:

var logger = new ksfLogs ('KsfDate', 'access', {
	format: ksfLogs.DateFormat.LogByDay
});

But if you need a custom interval or log file name, you need to instantiate:

var logger = new ksfLogs ('KsfDate', 'access', {
	format: new ksfLogs.DateFormat.LogByDay (3, '% Y-% m-% d');
});

For more information on DateFormat, please visit @ ksf / winston-ksf.DateFormat

Scroll logs by time (KsfDate)

When initializing a logger of typeKsfDate, options also accepts the following parameters:

• format: interval for creating a new file, as a DateFormat object, default value is FORMAT.LogByDay
• formatter: defines the log content formatting method. The default value is Formatter.Simple ()
• logTo: The destination of the log, which is LogTo enumeration, The default value is LogTo.Both

There are 3 items in the LogTo enumeration:

• LogTo.Remote: only remote log (ksf.ksflog.LogObj)
• LogTo.Local: only log local
• LogTo.Both: remote + local

Please note: Options.format can only beDateFormat.LogByCustom when LogTo.Local

For more information on KsfDate, please visit @ksfcore/winston-ksf.KsfDate

Remote Log (KsfRemote)

Due to the complexity of remote log implementation (and parameters), please visit winston-ksf.KsfRemote for details.

dyeing

At the time of writing each log, you can specify whether the log needs to be dyed (that is, the switch for dyeing is not at the time of initialization but when the log is written).

Only the logs output by KsfRotate and KsfDate can be dyed.

The dyed log is not only output according to the previous logic, but also an additional copy will be output under the same logic and placed in the $LOG_PATH$/ksf_dyeing/ directory.

The stain log is always output in full (ignore the current log level for output).

Dyeing objects

The staining object identifies the current staining status (whether staining is required and additional information).

Dyeing objects need to be generated by the method provided by @ ksf/dyeing.

For ease of use, this module encapsulates the generation method of dyed objects. You can get the dyeing object through logger.getDyeingObj().

Open stain

logger.getDyeingObj(true);

Open the dye and set the dyed val to guid and key to guidsn

logger.getDyeingObj (true, 'guid', 'guid | sn');

In practical applications, this method should not be called to generate dyeing objects, but should be used directly from other modules .

Other modules that conform to the dyeing standard will provide the Object.getDyeingObj() method, which can be used to get the dyeing object instead of using the module's methods.

For more information about dyeing, please visit @ksfcore/dyeing.

use

When you need to dye a log, you need to pass the staining object as the last parameter of thelogger specific method (log level).

Output the log content as data1 data2 and force the dyed log

logger.info ('data1', 'data2', logger.getDyeingObj (true));

Output the log content as data and dye the log based on the dyeing information on therpc.server call chain

ksf.TestImp.prototype.echo = function (current, i) {
   logger.info ('data', current.getDyeingObj ());
}

rpc For details on how to obtain dyed objects, please refer to @ksfcore/rpc