Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUESTION] Passing multiple pino logger instances to Fastify constructor #997

Open
Gunacan opened this issue Feb 20, 2024 · 2 comments
Open

Comments

@Gunacan
Copy link

Gunacan commented Feb 20, 2024

I have a Node.js api that uses Fastify. It's not a REST api or anything like that. All it does is, listen to certain Redis events and act on them, like sending some http calls to external apis.

Since there is no consumer of this api, logging is very important for debugging purposes, or to just see the audit log.

Currently I have two events, but there will be more. Each event handler does multiple things and a lot of things can go wrong in each event. For each event, I want to log not only the errors, but certain other things too, like "new event received, here is the payload", or "event with 'uuid' completed", etc.

Because of all of that, I want to have dedicated log files for each event, so it's a little easier to look for things when needed. Everything about "event 1" would be logged into "event-1-logs.log" file, and everything about "event 2" would be logged into "event-2-logs.log" file.

Since Pino comes built in with Fastify, I would like to utilize that.

I have been looking at the Pino docs, examples, tutorials, but I can't seem to find how we can achieve this. At first, I thought about child loggers, but they solve a different problem. I also thought about having multiple transports and have a custom level set on those transports, but I am not sure if this will do it. I am also thinking that there would be a simpler way to do it then this.

Basically I want to be able to do this:

    function eventOneHandler (server) {
        ....
        server.log.eventOneLogger('event completed'); // configured to log to 'event-1-logs.log'
    }

    function eventTwoHandler (server) {
        ....
        server.log.eventTwoLogger('event completed'); // configured to log to 'event-2-logs.log'
    }

Looks like the only way to achieve this is to create multiple pino instances by using the pino() function, which returns a logger instance. See below:

import pino from 'pino';

const eventOneLogger = pino({
    transport: {
        target: 'pino-pretty',
        options: {
            destination: './logs/event-1-logs.log',
            mkdir: true,
            colorize: false
        }
    }
});
eventOneLogger.info('first logger');

const eventTwoLogger = pino({
    transport: {
        target: 'pino-pretty',
        options: {
            destination: './logs/event-2-logs.log',
            mkdir: true,
            colorize: false
        }
    }
});
eventTwoLogger.info('second logger');

Is there any way to achieve this by using the Fastify constructor? Is there any way we can pass multiple logger instances to the logger property in the constructor?

Something like:

const server: FastifyInstance = Fastify({
        logger: [
            eventOneLogger: {...config options here},
            eventTwoLogger: {...config options here}
    });

Is this possible with Fastify and Pino? If not, what would you recommend?

Thank you in advance!

@Gunacan Gunacan changed the title Passing multiple pino logger instances to Fastify constructor [QUESTION] Passing multiple pino logger instances to Fastify constructor Feb 20, 2024
@jsumners
Copy link
Member

Pino writes logs in newline delimited JSON. This makes them queryable. See https://getpino.io/#/docs/help?id=filter-logs

@Gunacan
Copy link
Author

Gunacan commented Feb 20, 2024

Pino writes logs in newline delimited JSON. This makes them queryable. See https://getpino.io/#/docs/help?id=filter-logs

Thank you for the quick response, but is there a way to have dedicated files, to pass multiple logger instances to the Fastify constructor if I still choose to do it that way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants