github.com/letsencrypt/boulder@v0.20251208.0/docs/logging.md (about) 1 # Logging 2 3 Boulder can log to stdout/stderr, syslog, or both. Boulder components 4 generally have a `syslog` portion of their JSON config that indicates the 5 maximum level of log that should be sent to a given destination. For instance, 6 in `test/config/wfe2.json`: 7 8 ``` 9 "syslog": { 10 "stdoutlevel": 4, 11 "sysloglevel": 6 12 }, 13 ``` 14 15 This indicates that logs of level 4 or below (error and warning) should be 16 emitted to stdout/stderr, and logs of level 6 or below (error, warning, notice, and 17 info) should be emitted to syslog, using the local Unix socket method. The 18 highest meaningful value is 7, which enables debug logging. 19 20 The stdout/stderr logger uses ANSI escape codes to color warnings as yellow 21 and errors as red, if stdout is detected to be a terminal. 22 23 The default value for these fields is 6 (INFO) for syslogLevel and 0 (no logs) 24 for stdoutLevel. To turn off syslog logging entirely, set syslogLevel to -1. 25 26 In Boulder's development environment, we enable stdout logging because that 27 makes it easier to see what's going on quickly. In production, we disable stdout 28 logging because it would duplicate the syslog logging. We preferred the syslog 29 logging because it provides things like severity level in a consistent way with 30 other components. But we may move to stdout/stderr logging to make it easier to 31 containerize Boulder. 32 33 Boulder has a number of adapters to take other packages' log APIs and send them 34 to syslog as expected. For instance, we provide a custom logger for mysql, grpc, 35 and prometheus that forwards to syslog. This is configured in StatsAndLogging in 36 cmd/shell.go. 37 38 There are some cases where we output to stdout regardless of the JSON config 39 settings: 40 41 - Panics are always emitted to stdout 42 - Packages that Boulder relies on may occasionally emit to stdout (though this 43 is generally not ideal and we try to get it changed). 44 45 Typically these output lines will be collected by systemd and forwarded to 46 syslog. 47 48 ## Verification 49 50 We attach a simple checksum to each log line. This is not a cryptographically 51 secure hash, but is intended to let us catch corruption in the log system. This 52 is a short chunk of base64 encoded data near the beginning of the log line. It 53 is consumed by cmd/log-validator.