# Distributed Tracing

## Concept Description

The microservice architecture addresses many problems of single applications but has several drawbacks, for example, network instability may lead to latency.

In a single application, all the modules are running in the same process without interworking. However, in the microservice architecture, services are communicated through network, and we have to address network problems, such as latency, timeout, and segmentation.

As services expand, we can hardly monitor how data is transferred in the complex service architecture. How do we efficiently monitor network latency and visualize the data flows of services?

The distributed tracing system efficiently monitor network latency of the microservice and visualize data flow during the service.

## Zipkin

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on Google Dapper paper

ServiceComb integrates the automatic call tracing function provided by Zipkin, so that users can focus on service demands.

## Procedure

For microservice based on ServiceComb Java Chassis, add the following content to pom.xml

<dependency>
<groupId>io.servicecomb</groupId>
<artifactId>handler-tracing-zipkin</artifactId>
</dependency>


If the microservice is based on the API of Spring Cloud Zuul, such as the manager service of the workshop demo, add the following dependency:

<dependency>
<groupId>io.servicecomb</groupId>
<artifactId>spring-cloud-zuul-zipkin</artifactId>
</dependency>


### Configure tracing and data collection

Set addresses for the tracing processor and data collection in the microservice.yaml file.

cse:
handler:
chain:
Consumer:
default: tracing-consumer
Provider:
default: tracing-provider
servicecomb:
tracing:
collector: