Modern software is a team of programs, and slowness hides in the gaps between them.

Long ago, an application was one big program. If a page was slow, a developer opened that one program and looked for the slow part. Today, a single click on a website might wake up a dozen small programs, called services. One checks who you are, another looks up your cart, another calculates the price, another talks to a payment company, and each of them may ask a database for help. This style is called a microservices architecture.

It brings a new puzzle. When the page takes four seconds, which of those twelve services was slow? Each service keeps its own diary of what it did, but the diaries are on different machines and written in different times. Reading all of them and stitching a story together by hand is slow, tiring and often impossible when an incident is happening.

You need two words before Jaeger makes sense.

A span is a record of one piece of work. It has a name, such as “load cart”, a start time, an end time, and some labels called attributes that add detail, like which user or which database table was involved. A span also remembers which span started it, called its parent.

A trace is the whole family of spans that belong to one request, from the first click to the final answer. Every span in the family carries the same trace ID, which is a long unique number, and that shared number is how a tool knows the spans belong together. The spans are arranged like a family tree, with the first span as the ancestor and the others as children, grandchildren and so on.

Jaeger is a distributed tracing backend with a web screen on top.

Jaeger is an open-source platform for receiving, storing, searching and visualizing traces. The word is German for “hunter”, and the name fits, because engineers use it to hunt down the cause of slowness and errors. It was created at Uber to understand its huge web of services, was released as open source, and later became a graduated project of the Cloud Native Computing Foundation, the same neutral foundation that hosts Kubernetes and OpenTelemetry.

It is important to see what Jaeger does and does not do. Jaeger does not create the spans. Your application, helped by OpenTelemetry, creates them. Jaeger sits at the other end of the pipe. It accepts the finished spans, keeps them in a database, and offers a web page where you can search for traces and see them drawn out as a timeline.

One creates and ships, the other stores and shows.

OpenTelemetry, often shortened to OTel, is a vendor-neutral standard and a set of tools for producing telemetry, which means traces, metrics and logs. It gives you libraries for many programming languages, a standard data format and protocol called OTLP, and a separate program called the Collector. It is deliberately not a storage or display tool.

That gap is where Jaeger belongs. Your services use the OpenTelemetry libraries to create spans. The spans are sent over OTLP, either straight to Jaeger or through a Collector. Jaeger then stores the spans and shows them in its screen. Because OTLP is a shared language, you could later swap Jaeger for another tracing tool without changing your application code.

flowchart LR
  A["Your services with OpenTelemetry libraries"] -->|"OTLP"| C["OpenTelemetry Collector"]
  C -->|"OTLP"| J["Jaeger"]
  J --> S[("Trace storage")]
  U["Engineer in a browser"] --> UI["Jaeger web screen"]
  UI --> J
        

Read the diagram from left to right. The services on the left create spans. They hand them to a Collector, which is an optional middle helper that can batch, filter and forward the data. The Collector passes the spans to Jaeger. Jaeger writes them into storage, and an engineer, shown at the bottom, opens the web screen to search the stored traces.

Knowing where Jaeger came from explains why it looks the way it does.

Large internet companies discovered the tracing problem early. Google published a well-known research paper about its internal tracing system, and that paper inspired a wave of open-source tools. Jaeger was one of them, built inside Uber, where thousands of services needed to be understood together.

A small vocabulary unlocks the whole screen.

Notice how the words line up with OpenTelemetry. A span is a span in both worlds. What Jaeger calls a tag is an attribute in OpenTelemetry, and what Jaeger calls a log is an event. When Jaeger receives OTLP data it translates these names so everything appears in its familiar screen.

Jaeger was designed as a few small parts that can be scaled separately.

The first generation of Jaeger split the job into separate programs. Understanding them is still useful, because many production systems and many articles describe this layout, and because the same jobs exist in newer versions even when they are packaged differently.

flowchart LR
  APP["Application"] --> AG["Agent"]
  AG --> COL["Jaeger Collector"]
  COL --> Q["Queue such as Kafka"]
  Q --> ING["Ingester"]
  ING --> DB[("Storage")]
  COL -.->|"direct write in small setups"| DB
  DB --> QS["Query service"]
  QS --> UI["Web UI"]
        

The dotted line is important. In small systems the collector writes directly to storage and the queue and ingester are skipped. In busy systems the queue acts as a shock absorber. If traffic spikes, spans pile up in the queue instead of overwhelming the database, and the ingester drains them at a safe speed.

The newest design makes Jaeger and OpenTelemetry even closer relatives.

In the newer major version, Jaeger is packaged as a single program that is assembled from OpenTelemetry Collector building blocks. Instead of separate agent, collector and ingester programs, one binary can play several roles depending on how it is configured. The receiving side uses the same receivers found in the OpenTelemetry Collector, which is why OTLP support is natural and complete. The storage side and the query side are added as extensions designed for Jaeger.

This has practical benefits. You can use the familiar processors from the OpenTelemetry world, such as batching and tail-based sampling, inside Jaeger itself. You manage one kind of configuration file, using the same ideas of receivers, processors and exporters that Collector users already know.

flowchart LR
  IN["OTLP receiver"] --> P1["Processors such as batch and sampling"]
  P1 --> EX["Storage exporter"]
  EX --> ST[("Storage backend")]
  QE["Query extension"] --> ST
  QE --> UIX["Web UI"]
        

In the diagram, spans enter through a receiver, pass through processors that tidy or thin them out, and leave through a storage exporter into the database. A separate extension reads the same database to serve the web screen. The receive-process-export shape is exactly the one used by the OpenTelemetry Collector.

Follow one span from birth to the screen.

sequenceDiagram
  participant W as Web service
  participant P as Payment service
  participant L as OTel library
  participant J as Jaeger
  W->>P: Call with trace ID in header
  P-->>W: Reply
  W->>L: Span finished
  P->>L: Child span finished
  L->>J: Send batch of spans over OTLP
  J->>J: Store and index
        

The sequence shows that the services never talk to Jaeger directly about each other. They only talk to each other normally, passing the trace ID along. Each one reports its own span separately, and Jaeger reassembles the family because every span carries the same trace ID. Spans may arrive out of order or from different machines, and that is fine.

Jaeger understands the standard language of OpenTelemetry.

OTLP, the OpenTelemetry Protocol, is the standard way to carry telemetry between programs. It comes in two flavors on the wire: one uses a fast binary connection called gRPC, and the other uses ordinary web requests called HTTP. The usual port numbers are 4317 for the first and 4318 for the second. Jaeger can listen on both.

Jaeger is the viewer and manager; the database is a separate choice.

Jaeger does not invent its own database. It plugs into existing ones. Which one you choose changes cost, speed, and how much work you do to run it. Supported choices have changed over time, so always confirm the current list in the official documentation before deciding.

The web page is where the whole effort pays off.

The Jaeger web screen, by default served on port 16686, begins with a search form. You choose a service, optionally an operation, a time range, and filters such as a minimum duration or a particular attribute value. Typical searches are “show me slow checkouts in the last hour” or “show me traces with errors from the payment service”.

How to read a timeline

Look at the top bar first. It is the whole request, and its length is the total time. Beneath it, the child bars show the steps. Bars that sit side by side in the same column of time ran in parallel. Bars that step down like stairs ran one after another. The long bar is where most time went, and the thin gap between a parent starting and its first child starting is often time spent waiting or doing work inside the parent itself.

A made-up but realistic example of using Jaeger to find a cause.

An online shop notices that some checkouts take six seconds while most take one. Support receives complaints but cannot reproduce the problem. An engineer opens Jaeger, picks the checkout service, and filters for traces longer than five seconds.

flowchart TD
  A["Checkout request 6.0 s"] --> B["Check login 0.1 s"]
  A --> C["Load cart 0.2 s"]
  A --> D["Calculate price 0.3 s"]
  A --> E["Charge card 5.2 s"]
  E --> F["Fraud check 0.2 s"]
  E --> G["Call bank 4.9 s"]
        

The picture tells the story in seconds. Out of six seconds in total, charging the card takes five. Inside that step, the call to the bank is the culprit at almost five seconds. Login, cart and pricing are innocent. Instead of guessing and debugging twelve services, the team now talks to the bank integration owner and checks timeouts and retries.

Many traces together reveal the shape of the whole system.

One trace shows one request. A thousand traces together show how the whole system is wired. Jaeger can use the traces it holds to draw a dependency graph, a map where each circle is a service and each arrow means one service calls another. New team members find this map valuable, because the real wiring is often different from the old architecture drawing nobody updated.

Jaeger can also present a performance overview per service, showing request rate, error rate and duration, the familiar trio often called RED metrics. These figures are typically derived from the spans by an OpenTelemetry component that turns spans into metrics, called a connector, and stored in a metrics database. Setting this up needs extra pieces, so treat it as an optional step after basic tracing works.

Choosing which traces to store is the key cost-control decision.

A busy system may create millions of traces an hour. Storing all of them is expensive, and most of them are boring successful requests. Sampling means keeping only a fraction. The skill is keeping the right fraction.

From a laptop to a large cluster.

flowchart LR
  S1["Services"] --> OC["OpenTelemetry Collectors"]
  OC --> LB["Load balancer"]
  LB --> J1["Jaeger instance 1"]
  LB --> J2["Jaeger instance 2"]
  J1 --> DB[("Storage cluster")]
  J2 --> DB
  DB --> Q1["Query instances"]
  Q1 --> UI["Web UI behind login"]
        

This picture shows the mature layout. Application traffic first meets nearby OpenTelemetry Collectors, which smooth out bursts and apply rules. A load balancer spreads the work among several Jaeger instances. They all write to the same shared storage, and a separate group of query instances serves humans, with the web screen placed behind a login.

Traces are a detailed diary of your system, so protect them like one.

A trace can contain internal service names, database queries, user identifiers, and sometimes things a careless developer put in an attribute, such as an email address or a token. Anyone who can read your traces learns a great deal about your system.

The tool that watches everything also needs watching.

If Jaeger silently stops saving spans, you will discover it in the middle of an incident, which is the worst moment. Jaeger exposes its own health and performance numbers, and these should be collected and alarmed like any other production system.

A useful trick is to send a tiny, steady test trace on a schedule and check that it appears in Jaeger within a minute. This end-to-end heartbeat catches problems that individual numbers can miss, such as a broken network path between services and the receiver.

Jaeger is one of several good backends for OpenTelemetry traces.

Because OTLP is a shared language, choosing a backend is not a lifelong marriage. Here is a fair comparison of common options. Features change often, so use this as a starting map and not as a final verdict.

Repeating good habits and avoiding well-known traps.

A practical checklist for the first months.

How different kinds of teams use Jaeger.

No. They are separate open-source projects, both hosted by the Cloud Native Computing Foundation. OpenTelemetry produces telemetry, and Jaeger stores and visualizes traces. They work together through OTLP.

No. OpenTelemetry works with many backends. Jaeger is one popular choice for traces, and it is free to use.

Jaeger is focused on traces. Metrics and logs are normally kept in other tools, although Jaeger can show some performance views derived from spans.

The Jaeger project has moved away from its own client libraries and recommends OpenTelemetry libraries for creating spans. New work should use OpenTelemetry.

Not strictly. Applications can send OTLP straight to Jaeger. A Collector is recommended in production because it adds batching, retries, filtering and flexibility.

Commonly 4317 for OTLP over gRPC, 4318 for OTLP over HTTP, and 16686 for the web screen. Always confirm against your version and configuration.

Start with the in-memory all-in-one setup for learning. For a real system, Elasticsearch or OpenSearch is a common starting point because of flexible searching, provided your team can operate it.

Common reasons are sampling that dropped it, the time range being too narrow, a different service name than expected, spans not reaching Jaeger because of a network or port mistake, or data already removed by the retention rule.

Usually the trace ID was not passed along one of the calls, for example through a message queue or a library that was not instrumented. Fix the propagation at that hop.

There is a small cost for creating and sending spans. Batching, sampling and sending to a nearby Collector keep it low for most systems.

Many teams keep a few days to a couple of weeks, because most investigations happen soon after an incident. Longer retention for error traces is a common refinement.

Yes, if you use OTLP and OpenTelemetry libraries. Only the destination changes, ideally in one Collector setting, while application code stays the same.

Jaeger answers a simple but vital question: where did the time go inside a request that touched many services? OpenTelemetry supplies the spans and carries them over OTLP. Jaeger receives them, stores them in a database of your choice, and presents them as a searchable timeline, a comparison view and a map of service dependencies. The two projects are neighbors, not one product, and the shared protocol between them keeps you free to change either side.