# Assessing Database Contribution via Distributed Tracing for Microservice Systems
## 2 Related Work
### Distributed Tracing  
Due to the complexity, dynamics, and uncertainty at runtime, it becomes more difficult to understand, diagnose, and debug the microservice system [4]. Therefore, observability [17] is regarded as the basic requirement of microservice systems. As a significant means to achieve observability, distributed tracing has been widely accepted and practiced in the industry. According to the industrial research in [12], distributed tracing is mainly used in timeline analysis, service dependency analysis, aggregation analysis, root cause analysis, and anomaly detection for microservice systems. Google introduced the first distributed tracing system, Dapper [18], in 2010, which led to the rapid development of distributed tracing. In recent years, many active distributed tracing projects in the open-source community, such as Pinpoint [19], Zipkin [20], Jaeger [21], and SkyWalking [22], have followed fundamental principles and working mechanisms of Dapper. At the same time, specifications such as OpenTracing [23], OpenCensus [24], and OpenTelemetry [25] have been formulated within the industry.  
The data model adopted by the OpenTracing specification, shown in Figure 1, mainly involves two core concepts:  
* **Span**: A call between two services or threads is called a span. Several properties are recorded in the span, including the operation name, start and end timestamps, span tags, span logs, span context, etc.
* **Trace**: A directed acyclic graph composed of multiple spans is called a trace.  
For a specific system, a trace represents a complete process of processing business requests; a span represents a specific call in this business request. A request generates a unique trace ID and propagates throughout the trace, i.e., spans belonging to the same trace have the same trace ID. At the same time, each span also has a unique span ID; except for the outermost span, each span has a span as its own parent and is marked with parent ID. In addition, span context is the information transmitted in the trace along with distributed transactions. It generally records two parts: one is the data necessary to implement the trace, such as the trace ID, the span ID, and the data required by downstream services; the other is the user-defined data recorded as key-value pairs for subsequent analysis.  
At the same time, a lot of research has been conducted based on distributed tracing. [PERSON] et al. [26] proposed an approach, named MEPFL, of latent error prediction and fault localization for microservice applications by learning from system trace logs. [PERSON]  
Figure 1: Traces and spans in distributed tracing.  
et al. [3] proposed a graph-based approach of microservice trace analysis, named GMTA, for understanding architecture and diagnosing various problems, which includes efficient processing of traces produced on the fly and has been implemented and deployed in eBay. [PERSON] et al. [9] proposed a deep-learning-based microservice anomaly detection approach named DeepTraLog, which uses a unified graph representation to describe the structure of a trace, and trains models by combining traces and logs. In [27], with their novel trace representation and the design of deep Bayesian networks with posterior flow, [PERSON] et al. designed an unsupervised anomaly detection system called TraceAnomaly, which can accurately and robustly detect trace anomalies in a unified fashion. [PERSON] et al. [28] designed an approach to calculate service-based maintainability metrics from runtime data and implemented a prototype with a Zipkin integrator.