Slide 1 of 3

Follow a slow request across services, not just within one

What you’ll learn

When a request slows down as it crosses several services, your metrics and logs each show one piece of the picture. A trace shows the whole path, so you can see which service lost the time. This journey teaches you to read one.

Here’s what this journey covers:

  • What a trace is: How one request’s journey across services is captured as a trace
  • When to reach for a trace: When to reach for a trace instead of metrics or logs
  • The four-stage path: The stages that turn a request into a trace you can open
  • Reading a trace: Open a real trace and find where the request spent its time, without setting anything up

You won’t set tracing up for your own system here. Producing traces, carrying and storing them, and connecting them to your other signals are covered in the separate setup journey.

Journey duration

~40 minutes

Script

When a request slows down after crossing several services, the simple question turns out to be surprisingly hard to answer: which one lost the time? Metrics and logs each give you a piece, not the whole path.

That’s the gap a trace closes, and reading one is the skill this journey gives you.

You’ll learn what a trace is, where tracing fits next to the metrics and logs you already use, the four-stage path that turns a request into a trace, and how to open a real trace and find the slow spot without setting anything up.

Plan on about forty minutes.

Next