-
Notifications
You must be signed in to change notification settings - Fork 913
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
Optional simultaneous debug logging to second file? #5392
Comments
Already implemented for 0.12: 6ed5f31 |
Would it be feasible to have separate filtering for each log file like the above example? It appears that isn't currently implemented? |
Hmm, maybe we allow filename at the beginning of 'log-level', like:
Awkward, but allows |
That would be great, especially if it would allow for the same level of granularity as before. This way you can have your regular info level log and a channel specific debug log to another destination. |
@rustyrussell - just a quick question - would it look like this?
|
It would work fine either way but it would be cleaner and less error prone if you specify filenames only once per |
Fixes: ElementsProject#5392 Changelog-Added: config: `log-level` can be specified on a per-logfile basis.
Fixes: ElementsProject#5392 Changelog-Added: config: `log-level` can be specified on a per-logfile basis.
Fixes: ElementsProject#5392 Changelog-Added: config: `log-level` can be specified on a per-logfile basis.
Background
#5349 was helpful in enabling debug logging to zoom in on one particular peer node id. It would sometimes be useful when you know in advance how to reproduce an issue. The trouble however is with many rare issues you can't predict ahead of time like #5371 or you can't restart the daemon to change the log-level because doing so workarounds the problem like #5366. Thus if we want better info to always be available we need debug logging enabled. But the full debug firehose is too much to drink. It contains too many useless events that detract from your ability to see ordinary information in the regular info log.
Proposal: Add an optional simultaneous second log file
With the option for two log files you could have the best of both worlds. The normal log would remain useful while users can opt into a second debug log containing whatever firehose they want. That way when an unpredictable bug happens the best possible information is available for reporting.
Notes
log2
would be disabled by default.log2-file
can only be a file, notstdout
like the default behavior of the main log.logrotate
to rotate thelog2-file
every day with 7 days expiry. This should be long enough firehose retention to recover whatever info is needed from a recent event. SIGHUP should behave the same on both log files.Thoughts?
The text was updated successfully, but these errors were encountered: