Based on winston and winston-tars, a log component conforming to the TARS framework specification, It contains staining logs, rolling (size, time) logs.
npm install @tars/logs
Output rolling log
var logger = new tarsLogs ('TarsRotate');
Output daily log named access
var logger = new tarsLogs ('TarsDate', 'access');
Output daily logs named access, only local and not remote logs
var logger = new tarsLogs ('TarsDate', 'access', {
logTo: tarsLogs.LogTo.Local
});
Output an hourly log named access
var logger = new tarsLogs ('TarsDate', 'access', {
format: tarsLogs.DateFormat.LogByHour
});
Output a 20-minute scroll log named access in the format of 2015-01-01_10: 00
var logger = new tarsLogs ('TarsDate', 'access', {
format: new (tarsLogs.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));
No need to configure this if the service is running on the TARS 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 tarsLogs.setConfig (data) static method
data (String | Object)
can be a tars configuration file path or a configured (@tars/utils).Config
instance.
var tarsLogs = require ('@ tars / logs');
var logger = new tarsLogs (type, [name, options]);
type (String)
log type:
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:
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
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
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 @tars/winston-tars.Metadata
The priority of the log level is: INFO
< DEBUG
<WARN
< ERROR
<NONE
Among them, except that the default level of TarsRotate is DEBUG
, all others are INFO
.
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 TARS platform
:
Log Level Change
and automatically change the current log level.tars.application.server.logLevel
section in the TARS configuration file to configure the log level.Rolling logs by size (TarsRotate)
.The module provides two simplified log processing methods: Formatter.Simple () and complex Formatter.Detail ():
date time | PID | log level | file name and line number | content
datetime | contents
Different log types use different processing methods by default.
For more information on Formatter
, please visit @tars/winston-tars.Formatter
When initializing a logger
of type TarsRotate
, options
also accepts the following parameters:
For more information on TarsRotate
, please visit @tars/winston-tars.TarsRotate
Defines the processing method of time-related logs (TarsDate
, TarsRemote
) scrolling:
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 tarsLogs ('TarsDate', 'access', {
format: tarsLogs.DateFormat.LogByDay
});
But if you need a custom interval or log file name, you need to instantiate:
var logger = new tarsLogs ('TarsDate', 'access', {
format: new tarsLogs.DateFormat.LogByDay (3, '% Y-% m-% d');
});
For more information on DateFormat
, please visit [@ tars / winston-tars.DateFormat] (https://github.com/tars-node/winston-tars#dateformat)
When initializing a logger
of type TarsDate
, options
also accepts the following parameters:
There are 3 items in the LogTo
enumeration:
Please note: Options.format
can only be DateFormat.LogByCustom
when LogTo.Local
For more information on TarsDate
, please visit @tars/winston-tars.TarsDate
Due to the complexity of remote log implementation (and parameters), please visit winston-tars.TarsRemote for details.
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 TarsRotate and TarsDate 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$/tars_dyeing/
directory.
The stain log is always output in full (ignore the current log level for output).
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 @ tars/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 @tars/dyeing.
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
tars.TestImp.prototype.echo = function (current, i) {
logger.info ('data', current.getDyeingObj ());
}
rpc
For details on how to obtain dyed objects, please refer to @tars/rpc