We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

Reading Traces

Let's take a closer look at a full trace in Jaeger. This is my "create shortlink" trace:

You should have seen something similar in the last lesson. Notice a few things:

  1. The auth.validate_password span takes a long time. That makes sense; it's checking a password hash.
  2. The handler.shorten_link span is the actual business logic of the request
  3. The http.verify_destination child span is taking almost all of the time of the handler.shorten_link span.

This check was added with good intentions – who wants to redirect users to a broken link? – but it runs on every shortlink creation request and, aside from auth, is the hottest path in the application.

It tells us something simple: checking the destination URL is by far the most expensive part of the "create shortlink" operation: much slower than actually saving the link to disk.

We use OpenTelemetry + Google's Cloud Trace on Boot.dev. One of our favorite dashboards shows the slowest median traces by HTTP handler across our entire app. It helped us find out that our "boss fight" xp calculations were slowing down lesson submissions... even when a boss fight wasn't active!