Logs

Logs are discrete, timestamped events emitted by applications and infrastructure — a request handled, an error thrown, a background job completed. They are the most granular of the three original observability pillars, and usually the most expensive to store and search at volume.

Modern practice favors structured logging (JSON or key-value fields) over free-text messages, since structured fields can be indexed, filtered, and aggregated far more cheaply and reliably than parsing plain text after the fact.

Why logs matter

• They carry arbitrary detail. A log line can contain anything a developer decided was worth recording — a stack trace, a request payload, a business identifier — with no fixed schema.
• They’re the source of truth for “what exactly happened.” When a metric shows an anomaly and a trace shows which service was involved, logs from that exact request usually explain the specific cause.
• They support audit and compliance. Many regulatory and security requirements are only satisfiable with a durable, detailed event record — which is what logs provide.

Key concepts

• Structured vs. unstructured logging. Structured logs (e.g., JSON with consistent field names) are dramatically cheaper to query and correlate than free-text logs parsed with regexes at query time.
• Log levels. DEBUG, INFO, WARN, ERROR and similar levels let teams control verbosity and cost, and filter noise during incident response.
• Correlation IDs. Attaching a trace ID or request ID to every log line is what allows you to jump directly from a slow span in a trace to the exact logs it produced.
• Retention and cost. Because log volume scales with traffic, retention policy (how long logs are kept, and at what index depth) is usually the single biggest lever on logging cost.

Where logs fit with the other pillars

Metrics surface that something changed, traces show which request and which service, and logs supply the fine-grained detail — the exact error message, stack trace, or payload — needed to actually fix it. When the issue is resource consumption rather than an explicit error, continuous profiling fills in the gap that logs can’t: what the code was actually doing on-CPU at that moment.