---
title: "When to reach for a trace | Grafana Labs"
description: "Define observability and contrast metrics, logs, traces, and profiles so you know when to reach for a trace."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## 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.