Logs vs Metrics vs Traces: Which Observability Signal Should You Use?

Teams often pick one signal and treat the others as optional. A dashboard full of logs does not tell you the error rate. A latency chart does not tell you which downstream call was slow. A trace without a log still hides the exception message. OpenTelemetry's signals docs group them on purpose: traces are the path of a request, metrics are a measurement captured at runtime, and logs are a recording of an event.

What each signal actually is

Metrics are numbers aggregated over a window. The OpenTelemetry primer describes them as aggregations of numeric data — error rate, CPU, request rate — and the metrics concept page contrasts them with tracing: traces follow one request, metrics describe many requests as statistics. They stay small, which is why they work for alerts.

Logs are timestamped messages. The primer is clear that a log is not automatically tied to a user request. A line that says "payment failed" is useful. The same line with no request id, service name, or trace id forces you to guess which checkout it belonged to. Logs become much more useful when they are attached to a span or share its trace id.

Traces follow one request. A trace is one or more spans. A span is a single unit of work — name, timing, and attributes such as HTTP method, route, and status code. The primer's example is a page load that passes an API gateway, a backend, and a database. Each hop is a span. Together they are one trace, usually drawn as a waterfall. Distributed tracing matters when the bug does not reproduce on one machine.

Which question each one answers

The Microsoft engineering playbook puts the same split in operational terms: metrics for health and alerting, logs for the detail after a metric has pointed somewhere, traces to follow a request across services. Tracing is also how you find a bottleneck when the system is up but one step inside a request is slow.

A practical order of work

1. Define a few user-facing metrics. The primer distinguishes "the process is up" from "the user got the right result." Track request rate, error rate, and latency for the endpoints people actually use. Resource metrics (CPU, memory) sit next to those, not instead of them.
2. Make logs structured and correlatable. One JSON object per event, with a timestamp, severity, service name, and a request or trace id. Free-text lines are hard to filter once volume grows. The playbook warns that verbose logs get expensive; do not log every success at debug level in production.
3. Add traces where a request crosses a boundary. One service talking to a database can often be debugged from a timed log line. Two or more services, a queue, or a third-party API is where a trace pays for itself — the waterfall shows which span owned the time. The primer notes that logs alone usually lack the "where was this called from" context.
4. Correlate, do not collect in isolation. Put the trace id on the log line and on the metric attributes you can afford (route, status), so a spike in a chart opens the matching traces and those traces open the matching logs.

OpenTelemetry is the instrumentation layer, not the dashboard. Its job, in the project's own words, is to collect, process, and export those signals so you are not locked to one vendor's agent format. Where you store and graph them — and how long you retain each signal — is a separate choice. High-volume traces and debug logs cost more to keep than a handful of aggregated metrics. How much of each you retain depends on traffic and on which questions you must still answer a week later. That scope is set during discovery.

What to skip early

• Alerting on log text. A metric already counted the error. A log query as the only alert breaks when the message wording changes, and it is slower to evaluate.
• A trace on every function in a monolith on day one. Span the incoming request and the outbound calls (database, HTTP, queue). Add internal spans when a profile or a log says a specific function is the cost.
• High-cardinality labels on metrics. User id or raw URL on every time series multiplies storage. Keep those fields on spans and logs. Metrics want stable dimensions: route template, status class, service name.
• Treating "we have logs" as observability. The primer's test is whether you can troubleshoot a new failure without shipping more instrumentation first. A pile of unrelated lines usually fails that test.

How this shows up in a cloud setup

The same three signals apply on VMs, containers, and serverless. What changes is where the collector runs and which attributes you attach (region, revision, queue name). If you are deciding whether the app should be one deployable or many, the tracing need goes up as soon as a user request leaves the process — see monolith vs microservices and when to use Kubernetes. Serverless and containers change the collector story, not the definitions; that split is in serverless vs containers.

If you want this wired into the pipeline, the dashboards, and the on-call alerts together, that is cloud and DevOps consulting: instrumentation, retention, and the path from an alert to a trace to a log, scoped to the services you actually run.