When to reach for a trace

Understanding why a system behaves the way it does by looking at the data it produces is called observability. That data comes as four signals: metrics, logs, traces, and profiles. Monitoring tells you when a known problem happens; observability helps you understand why, including problems you didn’t predict. Tracing is one of the four signals.

What each signal answers

Signal	What it is	What it answers
Metrics	Numeric measurements over time, for example error rate or latency	Is something wrong?
Logs	Timestamped records of events inside one service	What happened in one place?
Traces	The path of one request across services	Where did the time go across services?
Profiles	Function-level CPU and memory data	Why is the code in a service slow?

The question only a trace answers

Reach for a trace when the question is “where did the time go across services?” That’s the service-to-service timing no other signal reconstructs. A metric tells you checkout is slow, a log tells you one service recorded an error, and a trace tells you which hop in the checkout path lost the time.

Step back from tracing for a moment. Understanding why a system behaves the way it does by reading the data it emits is observability, and that data arrives as four signals: metrics, logs, traces, and profiles.

It helps to separate two words that get mixed up. Monitoring tells you when a known problem happens. Observability helps you understand why, including the problems you never thought to predict.

Each signal answers a different question. Metrics tell you whether something is wrong. Logs tell you what happened inside one service. Traces tell you where the time went as the request crossed services. Profiles tell you why the code in a service is slow.

So reach for a trace when that last question is the one you’re asking. A metric says checkout is slow and a log shows one service’s error, but only the trace tells you which hop in the path actually lost the time.

When to reach for a trace