Structured logging

[tarcieri]

The KMS logging story is really bad right now (see #236). As an MVP it uses the most minimal logging solution available in Rust right now, but there are a number of others worth considering.

Problems

Crossed-out items are handled upstream in Abscissa now.

• ~~TTY dependent: the current logger detects a TTY and disables logging regardless of severity level, making it extremely difficult to use under systemd (see #236). This should get fixed ASAP.~~
• unstructured logging: the current logging solution is based on the Rust log crate which is a fairly simple least common denominator solution
• ~~feature limited: the current logger logs to a TTY, and that's about it. This is "fine" with the hack described in #236 in conjunction with systemd-journald but ideally the logging would be much more flexible/configurable~~

Structured Logging

• The log crate presently used by the KMS is exploring structured logging support: https://github.com/rust-lang-nursery/log/issues/149
• slog is a structured logging framework for Rust

Alternatives

• ~~tokio-trace~~ tracing is an advanced asynchronous logging framework for Rust which is compatible with the log crate. It definitely seems like the way to go if the KMS were to switch to tokio (which should hopefully be possible soon), but can be used without tokio via the existing log-crate compatibility.

[tarcieri]

Pretty much the whole stack right now uses the log crate. This makes tokio-trace seem particularly appealing for retrofitting more advanced logging immediately, as until https://github.com/rust-lang-nursery/log/issues/149 is sorted out it provides both backwards compatibility with log and a much more advanced/comprehensive logging solution.

Alternatively, slog seems like the best option for a native structured logging solution. We don't presently use tokio, so we wouldn't immediately benefit from the asynchronous tracing/logging support in tokio-trace.