Flyt Logger
A small logging library for use within flyt node integrations. Flyt Logger is a thin wrapper around the
winston logger and can send logs over UDP or Console.
Usage
Install
yarn add @flytio/flyt-logger
Create a FlytLogger instance
Create an instance of a logger using the factory constructor and then use it to get the logger instance. Preferably at the beginning of a request:
import { FlytLogger } from '@flytio/flyt-logger';
const logger = new FlytLogger();
Optionally you can pass requestId as a first parameter to the logger, and transport options as a second one.
You can use helper factory functions to do this. You can read more about options here
import {
createTransport,
FlytLogger,
TransportType
} from '@flytio/flyt-logger';
const logger = new FlytLogger('fsdh-4234-23jh', {
transports: [
createTransport(TransportType.File, fileOptions),
createTransport(TransportType.UDP, udpOptions),
createTransport(TransportType.Console, consoleOptions)
]
});
Use the logger
Once we have initialised we can use any of the logging methods available. Each logging method accepts a message and an optional metadata object if you wish to send any other data that you think appropriate.
logger.info('sendCollectionOrder request started');
logger.debug(`pos response: ${JSON.stringify(responseFromPos)}`);
logger.error(`order failed to send: ${JSON.stringify(error)}`);
Upgrade from winston 2 to winston 3
Upgrading from winston 2 to winston 3 meant lot of changes in the logger creation and usage, especially how the metadata is passed to the log.
The transport interface that our UPD logger must compile changed from
public log(level: string, msg: string, meta: any = {}, callback: any): void;
to
public log?(info: any, next: () => void): any;
That means that all the metadata are now passed in the info object.
Thankfully the backwards compatibility is ensured by winston logger here, but that comported changed in the way we're creating the logger and we're parsing the log messages in the UPD transport file:
- The winston logger must be created specifying the metadata format. That is attached in the flyt-logger.ts file, and will override every format passed as options on the logger creations:
//in flyt-logger.ts
const optionsWithFormat = {
...options,
format: winston.format.metadata(),
};
this.winston = winston.createLogger(optionsWithFormat);
- The udp-transport.ts
log
method had then changed to work only with this specific format, defined by winston.format.metadata()
:
info: {
message: string,
metadata: {
requestId: string,
timestamp: string,
appLine: string
}
}
Child loggers
With the logger version 3.1.0 we started using the child logger functionality of winston (available since the v3.2.1). This allow us to re-use the same UDP connection to send multiple logs, instead of creating a new UDP connection for every log.
That was a problem in high-volume traffic integrations because connections were left open after we've finished with the instance of the logger concerned with that request, making the integration crash intermittently when ran out of sockets.
You don't have to do anything in order to use the child loggers, just make sure you have installed flyt-logger version >= 3.1