pino
pino copied to clipboard
Change redaction at after logger instantiation
Is it possibly to change the redact
settings after logger instantiation (data to be redacted may change while service is running)?
Would it be possible to provide an async function instead?
Performance overhead would then depend on the fn implementation (e.g. does it use caching etc.?) and not affect pino
performance in general.
Unfortunately it will as that’s a tight hotpath. Deferring even just for a microtick is going to cause a measureable slowdown. Essentially, we should be writing things out as fast as possible, and depending on an external system for this processing can cause an excessive accumulation of data in memory. As a result, allowing async reduction is going to negate all benefit of using pino in the first place.
You're right. Would it be possible to modify the redact
property itself after logger instantiation?
That could be added. However it will be changed only on the current logger and its future children. The parent maintains no ties with its children.
Thanks, I'll play around with this topic for better understanding. Is modification of redaction something you would accept a PR for?
I think so, yes.
@davidmarkclements @jsumners wdyt?
I would be fine with it.
I think... that we could support async redaction as a transport if we go with worker thread transports in v6
Hey there, similar question about the base
option object that is passed in during logger instantiation. Would you be open to a PR that allows that base log fields to be updated dynamically for a logger instance and/or a child logger instance?
For context, my use case is that we have fields that we'd like to add to all following logs that only appear at a certain point in the lifecycle of a server request (after logger instantiation).
Closed by #1059 ?
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.