instruction: Implement distributed tracing with Architecture | Jaeger Docs Introduction &cir; Features Getting Started Architecture &cir; APIs &cir;...
output: Architecture | Jaeger Docs Introduction &cir; Features Getting Started Architecture &cir; APIs &cir; Sampling Deployment &cir; OpenTelemetry &cir; Kubernetes &cir; Frontend/UI &cir; CLI Flags &cir; Security &cir; On Windows Client Libraries &cir; Client Features Monitoring Jaeger Performance Tuning Guide Troubleshooting Frequently Asked Questions Tools Versions 2.9&nbsp;&nbsp;( latest ) 2.8 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.72&nbsp;&nbsp;( latest ) 1.71 1.70 1.69 1.68 1.67 1.66 1.65 1.64 1.63 1.62 1.61 1.60 1.59 1.58 1.57 Demo Download Blog Project Get involved Get in touch Mentorships Mentorships - For Mentees Mentorships - For Mentors News Roadmap Branding Report security issue Main GitHub repo Docs GitHub repo We stand with our friends and colleagues in Ukraine. To support Ukraine in their time of need visit this page . Introduction &cir; Features Getting Started Architecture &cir; APIs &cir; Sampling Deployment &cir; OpenTelemetry &cir; Kubernetes &cir; Frontend/UI &cir; CLI Flags &cir; Security &cir; On Windows Client Libraries &cir; Client Features Monitoring Performance Tuning Guide Troubleshooting FAQs Tools Architecture Version&nbsp;&nbsp; 1.21 Go to the latest 1.x version Go to the latest 2.x version See also: APIs Sampling Jaeger&rsquo;s clients adhere to the data model described in the OpenTracing standard. Reading the specification &#8201; external link will help you understand this section better. Terminology Let&rsquo;s start with a quick refresher on the terminology defined by the OpenTracing Specification &#8201; external link . Span A span represents a logical unit of work in Jaeger that has an operation name, the start time of the operation, and the duration. Spans may be nested and ordered to model causal relationships. Trace A trace is a data/execution path through the system, and can be thought of as a directed acyclic graph of spans . Components Jaeger can be deployed either as all-in-one binary, where all Jaeger backend components run in a single process, or as a scalable distributed system, discussed below. There are two main deployment options: Collectors are writing directly to storage. Collectors are writing to Kafka as a preliminary buffer. Illustration of direct-to-storage architecture Illustration of architecture with Kafka as intermediate buffer This section details the constituent parts of Jaeger and how they relate to each other. It is arranged by the order in which spans from your application interact with them. Jaeger client libraries Jaeger clients are language specific implementations of the OpenTracing API &#8201; external link . They can be used to instrument applications for distributed tracing either manually or with a variety of existing open source frameworks, such as Flask, Dropwizard, gRPC, and many more, that are already integrated with OpenTracing. An instrumented service creates spans when receiving new requests and attaches context information ( trace id, span id, and baggage ) to outgoing requests. Only the ids and baggage are propagated with requests; all other profiling data, like operation name, timing, tags and logs, is not propagated. Instead, it is transmitted out of process to the Jaeger backend asynchronously, in the background. The instrumentation is designed to be always on in production. To minimize the overhead, Jaeger clients employ various sampling strategies. When a trace is sampled, the profiling span data is captured and transmitted to the Jaeger backend. When a trace is not sampled, no profiling data is collected at all, and the calls to the OpenTracing APIs are short-circuited to incur the minimal amount of overhead. By default, Jaeger clients sample 0.1% of traces (1 in 1000), and have the ability to retrieve sampling strategies from the Jaeger backend. For more information, please refer to Sampling . Illustration of context propagation Agent The Jaeger agent is a network daemon that listens for spans sent over UDP, which it batches and sends to the collector. It is designed to be deployed to all hosts as an infrastructure component. The agent abstracts the routing and discovery of the collectors away from the client. Collector The Jaeger collector receives traces from Jaeger agents and runs them through a processing pipeline. Currently our pipeline validates traces, indexes them, performs any transformations, and finally stores them. Jaeger&rsquo;s storage is a pluggable component which currently supports Cassandra , Elasticsearch and Kafka . Query Query is a service that retrieves traces from storage and hosts a UI to display them. Ingester Ingester is a service that reads from Kafka topic and writes to another storage backend (Cassandra, Elasticsearch). Community Getting in touch Via chat Project video meetings Report issues on GitHub Report a security issue &copy; 2025 The Jaeger Authors. Documentation distributed under CC-BY-4.0 . &copy; 2025 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.