Set up metrics first so you know something is wrong, structured logs second so you can find out why, and traces third once a single request crosses enough services that logs alone cannot show where time went. Each signal answers a different question.
How each signal is defined
OpenTelemetry names three signals. Traces show the path of a request through your application. Metrics are measurements captured at runtime, such as memory use at a point in time. Logs are recordings of events.
The useful way to think about them is by question.
- Metrics: is something wrong, and how bad is it?
- Logs: what happened in this specific case?
- Traces: where did this request spend its time, and which call failed?
Why metrics come first
Metrics are cheap to store, quick to query and good for alerting. A few counters and a latency histogram per service give you the numbers behind the four golden signals from the Google SRE book: latency, traffic, errors and saturation. Alert on these, and you will hear about user facing problems.
Without metrics, teams find out from customers, or they grep logs by hand to count errors, which is slow and expensive.
Why logs come next
Once an alert fires, you need detail. Which tenant, which input, which downstream error. Structured logs with a request ID give that detail. They are also the record you need for security investigations and audits, which metrics cannot supply.
Logs cost more as volume grows, so decide early what you keep and for how long.
When traces earn their cost
Tracing pays off when:
- one request touches four or more services
- latency complaints are hard to pin on a service
- retries and parallel calls make the timeline unclear from logs
If you have a single service and a database, a good log line with a duration field often beats the effort of full tracing.
A sensible rollout order
- Metrics for request rate, error rate, latency and saturation, with two or three alerts.
- Structured logs with a shared schema and request ID.
- Log retention and access rules written down.
- Tracing on the busiest path, with the trace ID copied into logs.
- Runbooks for every alert that pages someone.
Avoid these traps
- Logging everything at debug level in production and paying for it
- Alerting on dozens of causes instead of a few symptoms
- Adding traces without a way to find them from a log line
Quick check
Can logs replace metrics?
You can derive counts from logs, but it is slower and costlier at scale. Keep a small set of real metrics for alerting.
Do I need all three on day one?
No. Metrics and structured logs cover most needs for a small system. Add traces when the call graph is the problem.
Sources
Last reviewed: 19 October 2026.
