Section 2 · Tracing basics

Define observability and contrast metrics, logs, traces, and profiles so you know when to reach for a trace.

Estimated time: 1 min

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

SignalWhat it isWhat it answers
MetricsNumeric measurements over time, for example error rate or latencyIs something wrong?
LogsTimestamped records of events inside one serviceWhat happened in one place?
TracesThe path of one request across servicesWhere did the time go across services?
ProfilesFunction-level CPU and memory dataWhy 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.