การติดตามแบบกระจายด้วย Sleuth/Zipkin

In a microservices architecture, a single user request often travels through many different services. This distributed nature makes it incredibly hard to track the flow of requests and pinpoint where issues occur.

Distributed tracing helps you visualize the full journey of a request across all services involved, making debugging and performance monitoring much easier.

Distributed tracing relies on two core concepts:

• Trace: Represents the complete journey of a request through a system, from start to finish. It's like a story of one operation.
• Span: A single, logical unit of work within a trace. Each operation (e.g., an HTTP request, a database call, sending a Kafka message) gets its own span. Spans have parent-child relationships, showing cause and effect.

Spring Cloud Sleuth is a powerful library for Spring Boot applications that automatically adds distributed tracing capabilities. It instruments your application to generate, collect, and propagate trace information.

• It automatically adds trace and span IDs to your logs.
• It propagates these IDs across service boundaries (HTTP, messaging, etc.).

This means you don't have to manually manage trace IDs in most cases!

To integrate Spring Cloud Sleuth into your Spring Boot project, add the following dependencies to your pom.xml:

• spring-cloud-starter-sleuth: The core tracing library.
• spring-cloud-sleuth-zipkin: Integrates with Zipkin for trace visualization.

After adding the dependencies, a minimal configuration in your application.properties is usually enough to get started. Sleuth will automatically detect and configure itself.

To send traces to a Zipkin server, specify its URL:

One of Sleuth's key features is its ability to propagate trace context across messaging systems like Kafka. When you use Spring's KafkaTemplate to send messages:

• Sleuth automatically injects trace and span IDs into the Kafka message headers.
• When a @KafkaListener receives the message, Sleuth extracts these headers and continues the trace, linking the producer's span to the consumer's span.

This creates a continuous trace, even across asynchronous Kafka message flows.

While Sleuth generates and propagates trace data, Zipkin is the distributed tracing system that collects, stores, and visualizes this data. It provides a user interface where you can:

• Search for traces by service name, timestamp, or trace ID.
• View a Gantt chart representation of a trace, showing the sequence and duration of spans.
• Identify performance bottlenecks and errors across your microservices.

For local development and testing, you can easily run a Zipkin server using Docker. This provides a quick way to see your traces without complex setup.

Here's a simple Spring Boot Kafka producer. With Sleuth and Zipkin configured (as shown in earlier scenes), when you run this, Sleuth will automatically add tracing headers to the Kafka message. You would see the traceId and spanId in your application logs and in the Zipkin UI.

When a Spring Boot application with Spring Cloud Sleuth sends a message to Kafka, which of the following statements are true about trace information?

You've learned about distributed tracing, a critical technique for understanding complex microservice interactions. We covered:

• The concepts of Trace (full request journey) and Span (individual operation).
• How Spring Cloud Sleuth automatically instruments Spring Boot applications, including Kafka producers and consumers, to propagate tracing context.
• The role of Zipkin in collecting and visualizing these traces, providing invaluable insights into your system's behavior.

With these tools, you can effectively monitor and debug your event-driven microservices!