บทนำสู่การติดตามการทำงานแบบกระจาย

In modern applications, especially those built with microservices, a single user request can travel through many different services. Distributed tracing is a technique that helps you follow a request's journey across these services.

It's like giving each request a unique ID and tracking its path, step-by-step, no matter how many services it touches.

Imagine a website where clicking a button involves your browser, a frontend service, an API gateway, an authentication service, a product database, and a recommendation engine. If something goes wrong, or it's slow, how do you know where the problem is?

Traditional logging often falls short here. Tracing gives you a holistic view of the entire transaction, making it easier to pinpoint issues.

In a traditional monolith (one big application), debugging is often simpler because all code runs in one place. You can use a debugger to step through its execution.

With microservices, your application is broken into many small, independent services. This offers flexibility but makes debugging request flows much harder, as they span multiple processes and machines.

Consider a simple e-commerce purchase transaction. A single 'buy' action from a user might involve:

• Your browser sending a request to the Frontend service.
• Frontend calling the Order service.
• Order service calling the Inventory service.
• Inventory service calling the Payment Gateway.
• Payment Gateway returning to Order service.
• Order service updating the Database.

Each step is a separate service. Tracing connects these dots.

The core concepts in distributed tracing are Traces and Spans.

• A Trace represents the entire end-to-end journey of a single request or transaction through a distributed system.
• A Span represents a single operation or unit of work within that trace. It could be a function call, an HTTP request, or a database query.

Each span captures important details about the operation it represents:

• Operation Name: What happened (e.g., authenticateUser, getProductDetails).
• Start/End Timestamps: When the operation began and finished.
• Duration: How long it took.
• Attributes (Tags): Key-value pairs providing context (e.g., http.method="GET", db.type="postgres").
• Logs/Events: Specific events that occurred during the span.

For a trace to be useful, spans must be linked together to show their parent-child relationships. This is done using trace context.

When a service calls another service, it passes along the trace context, which includes the current trace ID and the parent span ID. This ensures the receiving service can create a new child span that correctly belongs to the ongoing trace.

Every trace is identified by a unique Trace ID. All spans belonging to the same trace share this ID.

Each span also has its own unique Span ID. Additionally, a child span will have a Parent Span ID, which points to the span that initiated it. This mechanism forms a tree-like structure, visualizing the flow.

To collect tracing data, your application code needs to be instrumented. This means adding libraries or agents that automatically capture span information at key points (e.g., HTTP requests, database calls).

Many frameworks and languages have libraries that make instrumentation easier, often by auto-instrumenting common operations or providing APIs for custom spans. This allows data to be sent to a tracing backend.

We've introduced distributed tracing as a crucial technique for understanding request flows in complex, distributed systems. You learned about:

• The need for tracing in microservices.
• Traces (end-to-end request) and Spans (individual operations).
• How trace context and unique IDs connect spans.
• The concept of instrumentation for data collection.

Next, we'll explore specific tools and standards like OpenTelemetry that help implement these concepts!