Logging records readable information about a program’s execution so developers can inspect state, follow events, diagnose failures, and confirm recovery. A logger records these messages, but unconditional print statements are too inflexible for production use. section 4.0
Effective logging balances diagnostic value against storage cost:
- Write clear messages that identify what happened, rather than vague labels such as “step 1.” section 4.5
- Record useful measures such as processing time instead of repeating reassuring completion messages. section 4.5
- Avoid logging large maps, image data, audio data, or other unnecessary payloads; prefer sizes, presence checks, or separate storage. section 4.5
- Choose levels and content deliberately, excluding sensitive data and clutter. section 4.5 section 4.6
Finding an unexpected count
When a count should be 1 but appears to be 2, a temporary message such as “counting entries, current value is %d” can reveal the program’s state. A reusable logger preserves this diagnostic capability without redeploying unconditional printing, and can later direct output beyond standard output. section 4.0 section 4.2
{
"time": "2022-31-10 23:06:30.148845Z",
"level": "warning",
"message": "platform not scaled up for request"
}
A structured log entry makes time, severity, and message explicit, supporting later inspection and aggregation. section 4.5
