Distributed tracing (Jaeger, Zipkin) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the purpose of distributed tracing

Which of the following best describes the main purpose of distributed tracing tools like Jaeger and Zipkin in a microservices architecture?

A To automatically scale microservices based on incoming traffic patterns.

B To replace traditional logging systems by storing all logs in a centralized database.

C To monitor and visualize the flow of requests across multiple microservices to identify latency and errors.

D To encrypt all communication between microservices for enhanced security.

💡 Hint

Think about what problem distributed tracing solves in complex systems.

Distributed tracing tools help track requests as they travel through multiple microservices, making it easier to find where delays or errors happen.

❓ Architecture

intermediate

Key components of a distributed tracing system

Which component is NOT typically part of a distributed tracing system like Jaeger or Zipkin?

A Load balancer that distributes incoming user requests to microservices.

B Collector that receives and processes trace data from instrumented services.

C Storage backend that saves trace data for querying and visualization.

D Agent that runs alongside services to capture and forward trace data.

💡 Hint

Consider which components are specific to tracing versus general infrastructure.

Load balancers distribute traffic but are not part of the tracing system itself.

❓ scaling

advanced

Scaling distributed tracing in high-traffic microservices

In a high-traffic microservices environment, what is the best approach to ensure distributed tracing data does not overwhelm storage and processing systems?

A Store all trace data indefinitely to ensure complete historical records.

B Disable tracing on all services during peak traffic to avoid overload.

C Send trace data directly from clients to the storage backend without processing.

D Sample traces by collecting only a subset of requests to reduce data volume.

💡 Hint

Think about balancing data completeness with system performance.

Sampling reduces the amount of trace data collected, helping systems handle high traffic without losing all visibility.

❓ tradeoff

advanced

Tradeoffs in choosing between Jaeger and Zipkin

Which statement correctly describes a tradeoff when choosing between Jaeger and Zipkin for distributed tracing?

A Jaeger offers better integration with Kubernetes but Zipkin has a simpler architecture and easier setup.

B Zipkin supports more programming languages natively than Jaeger.

C Jaeger does not support sampling, while Zipkin supports advanced sampling techniques.

D Zipkin requires proprietary storage solutions, whereas Jaeger only supports open-source databases.

💡 Hint

Consider differences in deployment and architecture complexity.

Jaeger is designed with Kubernetes in mind and offers rich features, while Zipkin is known for its simplicity and ease of setup.

❓ estimation

expert

Estimating storage needs for distributed tracing data

A microservices system handles 100,000 requests per minute. Each trace generates approximately 10KB of data. If you sample 10% of traces for storage, what is the estimated storage needed per day (in GB)?

A Approximately 864 GB

B Approximately 144 GB

C Approximately 1,440 GB

D Approximately 86.4 GB

💡 Hint

Calculate total data per minute, apply sampling, then scale to one day.

Calculate: 100,000 requests/min * 10KB = 1,000,000 KB/min = 1,000 MB/min. Sampling 10% means 100 MB/min stored. For one day: 100 MB/min * 60 min * 24 hours = 144,000 MB = 144 GB.

Practice

1. What is the main purpose of distributed tracing tools like Jaeger or Zipkin in microservices?

easy

A. To track and visualize requests as they flow through multiple services

B. To store large amounts of user data securely

C. To replace load balancers in service communication

D. To encrypt network traffic between microservices

Solution

1. Step 1: Understand the role of distributed tracing

   Distributed tracing tools help monitor how requests move through different microservices by collecting timing and metadata.

2. Step 2: Identify the main function of Jaeger and Zipkin

   They visualize and analyze traces made of spans to find bottlenecks or errors in service chains.

3. Final Answer:

   To track and visualize requests as they flow through multiple services -> Option A

4. Quick Check:

   Distributed tracing = track requests flow [OK]

Hint: Distributed tracing = tracking requests across services [OK]

Common Mistakes:

• Confusing tracing with data storage
• Thinking tracing replaces load balancers
• Assuming tracing encrypts traffic

2. Which of the following is the correct way to propagate trace context between microservices using HTTP headers?

easy

A. Add Cookie header with span ID

B. Add Authorization header with trace ID

C. Add X-B3-TraceId and X-B3-SpanId headers to the outgoing request

D. Add Content-Type header with trace ID value

Solution

1. Step 1: Recall standard trace context headers

   Distributed tracing uses specific headers like X-B3-TraceId and X-B3-SpanId to pass trace info between services.

2. Step 2: Identify correct header usage

   Headers like Authorization, Content-Type, or Cookie are unrelated to tracing context propagation.

3. Final Answer:

   Add X-B3-TraceId and X-B3-SpanId headers to the outgoing request -> Option C

4. Quick Check:

   Trace context headers = X-B3-TraceId, X-B3-SpanId [OK]

Hint: Trace context uses X-B3 headers, not auth or content-type [OK]

Common Mistakes:

• Using unrelated HTTP headers for trace context
• Forgetting to propagate span ID
• Confusing trace ID with authentication tokens

3. Given the following trace spans collected by Zipkin, what is the total time taken by the root request?

Span A (root): start=0ms, duration=50ms
Span B (child of A): start=10ms, duration=20ms
Span C (child of A): start=35ms, duration=10ms

medium

A. 50ms

B. 40ms

C. 30ms

D. 60ms

Solution

1. Step 1: Understand root span duration

   The root span duration represents the total time of the entire request, including child spans.

2. Step 2: Analyze given spans

   Span A starts at 0ms and lasts 50ms, so total time is 50ms regardless of child spans.

3. Final Answer:

   50ms -> Option A

4. Quick Check:

   Root span duration = total request time = 50ms [OK]

Hint: Root span duration = total request time [OK]

Common Mistakes:

• Adding child spans durations incorrectly
• Ignoring root span duration
• Confusing start times with total duration

4. You notice that your distributed tracing data in Jaeger shows many missing spans for some services. What is the most likely cause?

medium

A. The network latency is too low

B. The services have too many CPU cores

C. The database is down

D. The services are not propagating the trace context headers correctly

Solution

1. Step 1: Identify cause of missing spans

   If spans are missing, it usually means trace context was not passed properly between services.

2. Step 2: Eliminate unrelated causes

   CPU cores, database status, or low network latency do not cause missing trace spans.

3. Final Answer:

   The services are not propagating the trace context headers correctly -> Option D

4. Quick Check:

   Missing spans = trace context not propagated [OK]

Hint: Missing spans? Check trace context propagation [OK]

Common Mistakes:

• Blaming unrelated system resources
• Ignoring header propagation
• Assuming network latency causes missing spans

5. You want to design a distributed tracing system for a microservices architecture with 100 services and high request volume. Which approach best ensures scalability and minimal overhead?

hard

A. Trace every request fully and store all spans in a single central database

B. Use sampling to trace only a subset of requests and propagate trace context with lightweight headers

C. Disable trace context propagation and log spans locally in each service

D. Use synchronous calls to the tracing backend for every span creation

Solution

1. Step 1: Consider scalability needs

   Tracing every request fully in a large system causes high overhead and storage issues.

2. Step 2: Identify best practice for high volume tracing

   Sampling reduces load by tracing only some requests, and lightweight headers keep propagation efficient.

3. Step 3: Eliminate poor options

   Disabling propagation loses trace linkage; synchronous calls add latency; central DB can bottleneck.

4. Final Answer:

   Use sampling to trace only a subset of requests and propagate trace context with lightweight headers -> Option B

5. Quick Check:

   Sampling + lightweight headers = scalable tracing [OK]

Hint: Sampling + lightweight headers = scalable tracing [OK]

Common Mistakes:

• Tracing all requests causing overhead
• Ignoring trace context propagation
• Using synchronous calls causing latency