24 / 67 · 06 Observability-Driven Testing · Structured Logging Best Practices← prev⊞ allnext →☰ Read as one page
4.5Logging Dos and Don'ts for Testability
| Do | Don't |
|---|---|
| Log at every significant state transition | Log raw request/response bodies (PII risk) |
| Include correlation IDs (trace_id, request_id) | Use string interpolation for log messages |
| Use consistent event names across services | Log at DEBUG level in production |
| Include timing data for operations | Log secrets, tokens, or passwords |
| Separate business events from technical events | Create logs only useful during development |
| Use structured fields for every variable value | Embed values in the message string |
Anti-Pattern: Values in Message Strings
# BAD -- values embedded in string, impossible to query
log.info(f"User {user_id} placed order {order_id} for ${total}")
# GOOD -- values as structured fields, queryable
log.info("order_placed", user_id=user_id, order_id=order_id, total_cents=total)