Can someone explain basic logging to me?

I saw an error in production and it didn't tell me anything useful about what actually went wrong — I need help understanding how to read this garbage output.

Logging is a fundamental engineering discipline with non-trivial subtleties that most tutorials completely ignore, so let's build this up systematically from first principles to production best practices rather than just giving you a snippet of code.

At its core logging serves two primary purposes: post-hoc forensic debugging and real-time observability. The difference between them is what determines your entire design space because they have fundamentally conflicting requirements at the infrastructure level, which many developers fail to reconcile properly. Forensic logs require completeness—you want every detail about a request's lifecycle so you can reconstruct the failure path offline with total fidelity. Real-time observability requires speed and queryability—the log volume must be manageable enough that your dashboard doesn't take forty seconds to render while an incident is active, which means aggressive sampling at high volume.

Now let's talk levels because this is where everyone makes their first mistake. The standard DEBUG/INFO/WARN/ERROR hierarchy was designed for human readability but it breaks down the moment you scale beyond a single process. In production I almost always map these to more granular tiers: TRACE (hot loop telemetry, disabled by default), DEBUG (per-request span data, enabled per service in canary deploys), INFO (business events — order created, payment processed, user registered), WARN (recoverable errors with context on what was retried and why), ERROR (unhandled exceptions that require immediate attention with stack trace attached). The key insight is that every level should be answerable to the question: "If this fired at 10,000 requests per second, would I still want it?"

Format matters enormously. Structured logging in JSON or Protobuf format is non-negotiable for anything above a hobby project because regexing unstructured log lines in ELK/Splunk/Grafana Loki is a maintenance nightmare that degrades linearly with your codebase size. Each log entry should contain an explicit correlation ID, the service name, the environment, and timestamped