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

Pino to Pino transport with filtering? #2104

Open
FoxxMD opened this issue Dec 9, 2024 · 1 comment
Open

Pino to Pino transport with filtering? #2104

FoxxMD opened this issue Dec 9, 2024 · 1 comment

Comments

@FoxxMD
Copy link

FoxxMD commented Dec 9, 2024

My end goal is to have a pino logger that logs to an additional destination when used within a specific scope within my application.

The intuitive, naive thought would be that I could use logger.child() and pass an additional destination so that only when the child logger is used is the additional destination logged to. I know this is not how child works, however.

I also see that it is not possible to add additional destinations to an existing pino instance.

My current solution is to build the "top-level" pino instance with an additional PassThrough stream in object mode as a destination, used in conjunction with multistream and other destinations. A "scoped" pino instance with just the destination I need is then created.
I then use stream.on('data', (str) => ...) and in the callback check if the log object contains certain properties at which point I pass the log object and level to the scoped pino instance. My implemention of this is working:

My implementation is working but it feels un-pino-like. Is there any way I could better use actual transports to pass logging between Pino instances? Or is there a better way I could go about achieve this desired result? Any insight into a better way to do this would be helpful, thanks.

@mcollina
Copy link
Member

I think yours is the only solution with the current design.

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