1.9 KiB
Logging
Boulder can log to stdout, syslog, or both. Boulder components generally have a
syslog portion of their JSON config that indicates the maximum level of
log that should be sent to a given destination. For instance, in
test/config/wfe2.json:
"syslog": {
"stdoutlevel": 4,
"sysloglevel": 6
},
This indicates that logs of level 4 or below (error and warning) should be emitted to stdout, and logs of level 6 or below (error, warning, notice, and info) should be emitted to syslog, using the local Unix socket method. The highest meaningful value is 7, which enabled debug logging. The default value for these fields is 6 (INFO) for syslogLevel and 0 (no logs) for stdoutLevel.
In Boulder's development environment, we enable stdout logging because that makes it easier to see what's going on quickly. In production, we disable stdout logging because it would duplicate the syslog logging. We prefer the syslog logging because it provides things like severity level in a consistent way with other components.
Boulder has a number of adapters to take other packages' log APIs and send them to syslog as expected. For instance, we provide a custom logger for mysql, grpc, and prometheus that forwards to syslog. This is configured in StatsAndLogging in cmd/shell.go.
There are some cases where we output to stdout regardless of the JSON config settings:
- Panics are always emitted to stdout
- Packages that Boulder relies on may occasionally emit to stdout (though this is generally not ideal and we try to get it changed).
Typically these output lines will be collected by systemd and forwarded to syslog.
Verification
We attach a simple checksum to each log line. This is not a cryptographically secure hash, but is intended to let us catch corruption in the log system. This is a short chunk of base64 encoded data near the beginning of the log line. It is consumed by cmd/log-validator.