---
title: "The benefit of traces | Grafana Labs"
description: "Why a slow request across several services is hard to diagnose with metrics and logs alone."
---

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

## Where did the time go across services?

A checkout request comes in slow. It doesn’t run in one place: it hops from the web service, to the cart service, to the payments service, to the inventory service, each running separately and passing the request along. Software built this way, from separate services running on different machines that cooperate to handle one request, is a **distributed system**. Each independently running part is a **service**, and the route the request takes from service to service is its **request path**.

## Why metrics and logs can’t answer it

You already have metrics and logs, but neither follows the request across the hops. Metrics tell you *something* is wrong, checkout is slow, without saying where. Logs show what happened inside a single service, then stop at that service’s edge. So the request crosses four services and neither signal points to *which* hop lost the time.

Each signal covers a different slice of the request path, and neither slice pinpoints the slow hop.

[Metrics cover the whole request path but only show something is wrong; logs cover a single service; the missing view spans every hop to show which hop lost the time](signal-coverage.svg "Metrics cover the whole request path but only show something is wrong; logs cover a single service; the missing view spans every hop to show which hop lost the time")

## The missing view

You need something that follows the single request along its whole path and records how long each hop took. That’s the view the rest of this journey builds toward.