58ae1df684
This PR is a bit in preparation for the slog work in #28187 . Our current test re logging mostly test the internals, but we have no real end-to-end test of the logging output. This PR introduces a simple reexec-based log tester. This also relies upon a special mode in geth, which can be made to eject a set of predefined log messages (only available if the build-tag `integrationtests` is used e.g. go run --tags=integrationtests ./cmd/geth --log.format terminal logtest While working on this, I also noticed a quirk in the setup: when geth was configured to use a file output, then two separate handlers were used (one handler for the file, one handler for the console). Using two separate handlers means that two formatters are used, thus the formatting of any/all records happened twice. This PR changes the mechanism to use two separate io.Writers instead, which is both more optimal and fixes a bug which occurs due to a global statefulness in the formatter. |
||
---|---|---|
.. | ||
CONTRIBUTORS | ||
doc.go | ||
format_test.go | ||
format.go | ||
handler_glog.go | ||
handler.go | ||
LICENSE | ||
logger_test.go | ||
logger.go | ||
README_ETHEREUM.md | ||
README.md | ||
root.go | ||
syslog.go |
log15
Package log15 provides an opinionated, simple toolkit for best-practice logging in Go (golang) that is both human and machine readable. It is modeled after the Go standard library's io
and net/http
packages and is an alternative to the standard library's log
package.
Features
- A simple, easy-to-understand API
- Promotes structured logging by encouraging use of key/value pairs
- Child loggers which inherit and add their own private context
- Lazy evaluation of expensive operations
- Simple Handler interface allowing for construction of flexible, custom logging configurations with a tiny API.
- Color terminal support
- Built-in support for logging to files, streams, syslog, and the network
- Support for forking records to multiple handlers, buffering records for output, failing over from failed handler writes, + more
Versioning
The API of the master branch of log15 should always be considered unstable. If you want to rely on a stable API, you must vendor the library.
Importing
import log "github.com/inconshreveable/log15"
Examples
// all loggers can have key/value context
srvlog := log.New("module", "app/server")
// all log messages can have key/value context
srvlog.Warn("abnormal conn rate", "rate", curRate, "low", lowRate, "high", highRate)
// child loggers with inherited context
connlog := srvlog.New("raddr", c.RemoteAddr())
connlog.Info("connection open")
// lazy evaluation
connlog.Debug("ping remote", "latency", log.Lazy{pingRemote})
// flexible configuration
srvlog.SetHandler(log.MultiHandler(
log.StreamHandler(os.Stderr, log.LogfmtFormat()),
log.LvlFilterHandler(
log.LvlError,
log.Must.FileHandler("errors.json", log.JSONFormat()))))
Will result in output that looks like this:
WARN[06-17|21:58:10] abnormal conn rate module=app/server rate=0.500 low=0.100 high=0.800
INFO[06-17|21:58:10] connection open module=app/server raddr=10.0.0.1
Breaking API Changes
The following commits broke API stability. This reference is intended to help you understand the consequences of updating to a newer version of log15.
- 57a084d014d4150152b19e4e531399a7145d1540 - Added a
Get()
method to theLogger
interface to retrieve the current handler - 93404652ee366648fa622b64d1e2b67d75a3094a -
Record
fieldCall
changed tostack.Call
with switch togithub.com/go-stack/stack
- a5e7613673c73281f58e15a87d2cf0cf111e8152 - Restored
syslog.Priority
argument to theSyslogXxx
handler constructors
FAQ
The varargs style is brittle and error prone! Can I have type safety please?
Yes. Use log.Ctx
:
srvlog := log.New(log.Ctx{"module": "app/server"})
srvlog.Warn("abnormal conn rate", log.Ctx{"rate": curRate, "low": lowRate, "high": highRate})
License
Apache