@flytio/flyt-logger

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:

// main.ts

import { FlytLogger } from '@flytio/flyt-logger';

const logger = new FlytLogger();

Optionally you can pass requestId as a first parameter to the logger, a transport options as a second one, and a jobId as a third 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 reqId = 'fsdh-4234-23jh';
const jobId = '123';
const logger = new FlytLogger(
  reqId,
  {
    transports: [
      createTransport(TransportType.File, fileOptions),
      createTransport(TransportType.UDP, udpOptions),
      createTransport(TransportType.Console, consoleOptions),
    ],
  },
  jobId
);

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.

// Info messages should be a simple meesage describing what is happening.
logger.info('sendCollectionOrder request started');

// Debug messages should have more context.
logger.debug(`pos response: ${JSON.stringify(responseFromPos)}`);

// Error messages should log out any errors that happen in your application.
logger.error(`order failed to send: ${JSON.stringify(error)}`);

Note that any messages over 60,000 bytes (a bit under the UDP message limit of 65,535 bytes) will be truncated, as otherwise they would cause the application to silently fail (addresses this issue).

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:

1. 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);
   

2. 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