Book Image

Mastering Distributed Tracing

By : Yuri Shkuro
Book Image

Mastering Distributed Tracing

By: Yuri Shkuro

Overview of this book

Mastering Distributed Tracing will equip you to operate and enhance your own tracing infrastructure. Through practical exercises and code examples, you will learn how end-to-end tracing can be used as a powerful application performance management and comprehension tool. The rise of Internet-scale companies, like Google and Amazon, ushered in a new era of distributed systems operating on thousands of nodes across multiple data centers. Microservices increased that complexity, often exponentially. It is harder to debug these systems, track down failures, detect bottlenecks, or even simply understand what is going on. Distributed tracing focuses on solving these problems for complex distributed systems. Today, tracing standards have developed and we have much faster systems, making instrumentation less intrusive and data more valuable. Yuri Shkuro, the creator of Jaeger, a popular open-source distributed tracing system, delivers end-to-end coverage of the field in Mastering Distributed Tracing. Review the history and theoretical foundations of tracing; solve the data gathering problem through code instrumentation, with open standards like OpenTracing, W3C Trace Context, and OpenCensus; and discuss the benefits and applications of a distributed tracing infrastructure for understanding, and profiling, complex systems.
Table of Contents (21 chapters)
Mastering Distributed Tracing
Contributors
Preface
Other Books You May Enjoy
Leave a review - let other readers know what you think
15
Afterword
Index

Partial sampling


Let's conclude the overview of the sampling techniques with an approach used in some tracing systems where sampling decision does not guarantee consistent collection of all spans of a trace. It does not mean the sampling decision is made completely randomly at every node of the call graph, but rather that only a portion of the call graph is sampled. Specifically, the sampling decision can be made after detecting an anomaly in the trace, such as unusual latency or an error code. The tracing library is changed slightly to keep all the spans for currently active traces in memory until the entry span is finished. Once the sampling decision is made, we send all those spans to the tracing backend. Even though we will miss the spans from any downstream calls we already made from this service, as they finished the execution without being sampled, at least the inner workings of the current service will be represented in the trace, and we will be able to see which downstream systems...