Reliable, performant logging
- Dominant language
- Go
- Stars
- 17.1k
- Forks
- 3.2k
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 11
Description
We've recently switched from a custom logging backend to zap as our logging backend. The upside is structured logging but there are quite a few downsides:
* [ ] We need to re-implement the "mirror" logging logic. That is, we need to be able to add/remove additional sinks (e.g., a `ipfs log tail` sink) at runtime.
* [ ] The default file backend is unbuffered. This has terrible performance.
* [ ] The new backend _blocks_ if we log too much. We should log till we fill up a reasonable buffer, then start dropping messages.
* [ ] We've currently implemented multiple logging subsystems through multiple independent loggers. Instead, we should have a _single_ zap core.
Contributor guide
Assessment
This issue has not been assessed yet.