You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2020. It is now read-only.
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.
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 Log output (stdout) missing when running as systemd service #236 in conjunction with systemd-journald but ideally the logging would be much more flexible/configurable
tokio-tracetracing 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.
The text was updated successfully, but these errors were encountered:
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 rust-lang/log#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.
tarcieri
changed the title
Logging improvements
Structured logging
Aug 1, 2019
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 Log output (stdout) missing when running as systemd service #236). This should get fixed ASAP.log
crate which is a fairly simple least common denominator solutionfeature limited: the current logger logs to a TTY, and that's about it. This is "fine" with the hack described in Log output (stdout) missing when running as systemd service #236 in conjunction withsystemd-journald
but ideally the logging would be much more flexible/configurableStructured Logging
log
crate presently used by the KMS is exploring structured logging support: Structured Logging rust-lang/log#149Alternatives
tokio-tracetracing is an advanced asynchronous logging framework for Rust which is compatible with thelog
crate. It definitely seems like the way to go if the KMS were to switch totokio
(which should hopefully be possible soon), but can be used withouttokio
via the existinglog
-crate compatibility.The text was updated successfully, but these errors were encountered: