Improve logging
It's a little tangled right now. We don't log stream calls at all. Storage layer errors propagate to the network responses (#5) and all sorts of other leaks.
https://godoc.org/github.com/grpc-ecosystem/go-grpc-middleware/logging/logrus
Logging can also be more consistent. Currently, there are (I think) two forms of logging calls (or maybe these are the most common); an example of the simpler way:
log.Error("Error adding block to cache: ", err)
There is also a more elaborate way, for example:
log.WithFields(logrus.Fields{
"bind_addr": opts.bindAddr,
"error": err,
}).Error("couldn't create listener")
It's very nice that the entire log file is a series of JSON objects, so tools like jq can be used to select and manipulate the various fields. The second form of logging presents the given values as separate JSON fields, which may be useful for processing by jq. The first method puts the entire string as a value of the msg JSON field. The elaborate form makes the source code more cluttered and harder to read.
So all the logging should probably be reviewed to make sure we're logging important things, and only important things. There are also various logging levels that should be considered.
This may be an ongoing project; this work doesn't have all be done up-front, and in fact, that would be very difficult because it's hard to predict which information will be useful to log. But at least we can make one quick pass and fix the obvious problems.
It would be nice to enable selective logging by category, rather than just level (an integer). This is how zcashd logging is done, see the --debug command-line argument.
It may also be nice to allow logging to be enabled and disabled at runtime (using a gRPC), rather than only when the process starts.
It would be nice to enable selective logging by category, rather than just level (an integer). This is how
zcashdlogging is done, see the--debugcommand-line argument.It may also be nice to allow logging to be enabled and disabled at runtime (using a gRPC), rather than only when the process starts.
In Zebra we're using the https://github.com/tokio-rs/tracing library, which has those capabilities and is indeed quite nice. Unfortunately I don't know of an equivalent for Go, but you could probably build these on top of logrus.