Pino integration wraps all loggers (sometimes undesired)

[lforst]

Problem Statement

🥔 for shipping the pino integration. We looked at it and immediately found a potential issue with our setup, which is that we have multiple loggers/logger-streams and we would only like one of them to be sent to Sentry. Currently from what I understand, it looks like the integration just blanket wraps all of the loggers with IITM.

Solution Brainstorm

Multiple options I could quickly come up with:

• Add some API for transports/destinations
• Allow to wrap individual loggers (but also make it so that child logger logging statements are instrumented)

Additional Context

No response

[linear]

JS-1044

[Lms24]

Hello :D

Thanks for the feedback! Gonna ask @AbhiPrasad and @timfish to take a look and assess this further.

PRs are welcome :)

[AbhiPrasad]

yeah we should definitely allow for finely grained access here, we just need to figure out how we can subscribe to the correct channels accordingly. Does pino_asJson give us this ability @timfish?

[timfish]

We have access to the Pino instance from the diagnostics channel events. Could we use this to detect something useful?

[AbhiPrasad]

Could we grab the pino logger name?

Ideally this is an opt-out API, so users can somehow annotate their loggers to tell us not to send them to Sentry.

[timfish]

The only way to get the name is to change to hook the end of the call rather than the start. Then we'd need to parse the JSON output to get the name.

We could change the integration so it can be either opt-in or opt-out.

Then you could enable/disable something like this?

import { enablePino, disablePino } from '@sentry/node';

const logger = pino({});

enablePino(logger);

disablePino(logger);

These methods would add/remove a property to the Pino object with a symbol as a key. Almost everything on the Pino object uses symbol keys!