Logging
Overview
Logging records important system events so failures and behavior can be understood later.
Why It Matters
Logs are often the fastest way to see what actually happened before a failure.
Core Concepts
- Logs should be structured and searchable.
- Important events need context.
- Log noise makes real issues harder to find.
Mental Models
Log for the person on call, not for the code path.
Best Practices
- Include request IDs or trace IDs.
- Log at meaningful boundaries.
- Avoid logging secrets or excessive noise.
Common Mistakes
- Logging too much or too little.
- Missing correlation identifiers.
- Printing sensitive information.
Trade-offs
Detailed logs help debugging, but they increase cost and risk if they are not curated.
Decision Framework
| Event | Log it? |
|---|---|
| Request start/end | Yes, if useful for tracing |
| Secret value | No |
| Error boundary | Yes |
Examples
- Log an auth failure with enough context to trace the request, not the password.
Checklists
- Are logs structured?
- Can the event be correlated across services?
- Are sensitive values excluded?
Senior Engineer Notes
Senior engineers use logs like breadcrumbs. The point is to reduce search time during real problems.