feat!: worker friendly logger instances #5490
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Performance Report✔️ no performance regression detected Full benchmark results
|
dapplion
changed the title
packages/logger/package.json
Outdated
Comment on lines
16
to
29
| "exports": { | ||
| ".": { | ||
| "import": "./lib/index.js" | ||
| }, | ||
| "./browser": { | ||
| "import": "./lib/loggers/browser.js" | ||
| }, | ||
| "./node": { | ||
| "import": "./lib/loggers/node.js" | ||
| }, | ||
| "./empty": { | ||
| "import": "./lib/loggers/empty.js" | ||
| } | ||
| }, |
There was a problem hiding this comment.
Instead of subpath exports why not not use conditional exports https://nodejs.org/api/packages.html#conditional-exports. And only default export. This way user can use a consistent import pattern.
"exports": {
".": {
"node": "./lib/loggers/node.js",
"browser": "./lib/loggers/browser.js",
"default": "./lib/index.js"
},
},
wemeetagain
approved these changes
May 15, 2023
nflaig
reviewed
May 29, 2023
| // Return a new logger instance with different module and log level | ||
| // but a reference to the same transports, such that there's only one | ||
| // transport instance per tree of child loggers | ||
| child(opts: LoggerNodeChildOpts): LoggerNode { |
There was a problem hiding this comment.
@dapplion This changed how we create child loggers, it creates a new event listener for each child logger
Was the previous implementation not compatible when using workers?
Using native winston.child does not work as mention in previous comment.
Workaround for now is to just increase max listeners which should be fine to do as explained in the PR
There was a problem hiding this comment.
Hmm unsure of the reason forgot to document, so may be an oversight. Could you test if the previous approach works fine still?
There was a problem hiding this comment.
Child loggers are only created in the main thread, does not affect workers at all because we initialize a completely new logger instance there
Opened a PR to revert logger.child implementation back to original approach
nflaig
reviewed
May 29, 2023
| const filename = opts.file.filepath; | ||
|
|
||
| transports.push( | ||
| opts.file.dailyRotate != null |
There was a problem hiding this comment.
What's the expected approach to disable log file rotation now?
The comment above does not longer match behavior as setting --logFileDailyRotate 0 will still initialize DailyRotateFile. Default winston.transports.File is effectively never used now.
There was a problem hiding this comment.
Right, logFileDailyRotate is a bit a weird UX flag. Does yargs support accepting both syntax with no arg --logFileDailyRotate and with arg --logFileDailyRotate 5? That would make handling easier
There was a problem hiding this comment.
Both works, but setting --logFileDailyRotate (without value) and omitting the flag will result in 5 due to the fact that we set it as default here
Setting it to 0 to disable daily file rotation seems logical to me (and is most explicit), that's also how it worked previously
|
🎉 This PR is included in v1.9.0 🎉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Our current Logger instances are not DX friendly to support workers.
Let's list the requirements:
@lodestar/light-clientor@lodestar/reqrespjust want access to a generic simple Logger instance to write data at some LogLevel. No need to expose them to more complicated loggers or to force dependencies on NodeJS specific code@lodestar/beacon-nodeneed access to a generic logger with more features, specifically:2.1. Create child logger with custom settings, which must re-use references to the same transport instances
2.2. Serialize a logger instance settings and transport settings for a worker downstream
@lodestar/clihas to be able to produce compatible logger instances for the above casesDescription
So to fulfill 1. and 2. there must exist separate insterfaces, which are:
LoggerLoggerNodeLoggerNodecan export its settings withtoOpts()and be recreate with those