แนวคิดการติดตามแบบกระจาย

In a microservices world, a single user request can involve many different services talking to each other. It's like a relay race!

But what happens if one part of this race is slow, or fails entirely? How do you find the exact point of failure or bottleneck?

Distributed tracing is a technique that lets you follow the path of a single request as it travels through all the different services in your system.

It gives you a detailed 'journey map' for every request, showing you exactly where it went and what happened at each stop.

For microservices, tracing is vital because:

• Complexity: Interactions between many services are hard to visualize.
• Latency: Helps pinpoint which service is slowing down a request.
• Error Root Cause: Quickly identifies which service caused an error, rather than just knowing an error occurred.

The entire journey of a single request from start to finish is called a Trace. Think of it as the complete narrative of that request.

Every trace has a unique identifier, allowing you to link all parts of the request together, no matter how many services it touches.

Within a trace, each individual operation or unit of work performed by a service is called a Span.

• An API call to another service
• A database query
• Processing a message from a queue

Each span has a name, a start time, and an end time.

Spans aren't just a flat list; they form a hierarchy. When one service calls another, the calling service's span becomes the parent of the called service's span.

This creates a tree-like structure, showing the exact flow and dependencies between operations.

How do services know they're part of the same trace? Through context propagation.

When a service makes a request to another, it passes along crucial tracing information:

• The unique Trace ID
• Its own Span ID (so the next service can link its span as a child)

Let's trace a user login request:

• Frontend Service: Creates Trace ID, Span A (login request).
• Calls Auth Service: Passes Trace ID, Span A as parent. Auth Service creates Span B (validate credentials).
• Auth Service calls User Profile Service: Passes Trace ID, Span B as parent. User Profile Service creates Span C (fetch user data).

All spans are linked, forming a single, clear trace of the login process.

Specialized tools (like Jaeger or Zipkin) collect these traces and visualize them. You can see:

• A timeline of all spans for a request.
• Which spans took the longest.
• Any errors within a specific span.

This visual insight is incredibly powerful for debugging!

We've learned that distributed tracing provides crucial visibility into the complex interactions of microservices. By understanding traces, spans, and context propagation, you can effectively diagnose performance issues and pinpoint error sources.

This capability is a cornerstone of observability, helping you keep your distributed systems healthy and performant. Next, we'll explore centralized logging strategies.