Set Up Distributed Tracing in Istio with Jaeger (2026)

Istio’s distributed tracing isn’t just about seeing requests hop between services; it’s primarily a tool for understanding and debugging asynchronous communication patterns that are otherwise invisible.

Let’s see Istio tracing in action. Imagine a simple scenario: a frontend service (frontend) calls an API service (api), which in turn calls a database service (db). Without tracing, if api is slow, you’d just see frontend taking a long time. With tracing, you’d see the individual call to db from api as the culprit.

Here’s a simplified request flow and how it might look in Jaeger.

Request Initiation (Frontend): A user requests a page. The frontend service receives this. Istio’s Envoy proxy, acting as the sidecar for frontend, intercepts the outgoing request to api.

Trace Propagation: Envoy on the frontend sidecar generates a root trace ID and a span ID for its own operation. It then injects standard B3 tracing headers (like x-b3-traceid, x-b3-spanid, x-b3-sampled) into the request it forwards to the api service.

Span Creation and Propagation (API): When the request reaches the api service’s Envoy sidecar, it sees the incoming B3 headers. It uses the existing trace ID and generates a new span ID for its own operation. It then forwards the request to the actual api application. If the api application itself generates spans (e.g., by using a tracing-aware library), it would read the incoming headers, create its own span, and inject those same headers (with its own span ID) into any outgoing requests it makes, like to the db service.

Span Creation and Reporting (Database): The db service’s Envoy sidecar receives the request, again sees the B3 headers, and creates a span for the db call.

Span Reporting: Crucially, each Envoy proxy, after processing a request or response, sends its span data to a configured tracing backend. In our case, this is Jaeger. The Envoy proxy doesn’t wait for the full request to complete; it reports its span as soon as it has the necessary information (request start, duration, response code).

Jaeger UI: In Jaeger, you’d see these spans linked together by the shared trace ID. The frontend span would be the parent of the api span, and the api span would be the parent of the db span. The duration of each span shows you exactly where the latency is occurring.

Configuration in Istio:

To enable this, you need to configure Istio to send tracing data to Jaeger. This is typically done via the Istio operator configuration or by applying Istio configuration resources.

Install Jaeger: If you haven’t already, install Jaeger in your cluster. A common way is using the istioctl command:
```
istioctl install --set profile=demo --set addonComponents.jaeger.enabled=true
```
This command installs Istio with the demo profile and ensures Jaeger is deployed.
Configure Tracing in Istio: The Istio control plane needs to know where to send trace data. This is usually set in the meshConfig of the Istio operator or a istio-system namespace configuration.

For newer Istio versions (1.10+), this is often managed via the IstioOperator custom resource. You’d ensure your IstioOperator definition includes something like this:
```
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100 # Sample 100% of requests
        zipkin: # Istio uses Zipkin v2 protocol for reporting to Jaeger
          address: jaeger-collector.istio-system.svc.cluster.local:9411
```
- enableTracing: true: This globally enables tracing in Istio.
- sampling: 100: This tells Istio to generate trace data for every single request. For production, you might lower this to, say, 1 (1%) to reduce overhead.
- zipkin.address: This is the crucial part. Istio’s Envoy proxies report traces using the Zipkin v2 API. Here, jaeger-collector.istio-system.svc.cluster.local:9411 is the default Kubernetes service name and port for the Jaeger collector. Replace istio-system if you installed Jaeger in a different namespace.
If you are using older Istio versions or a different installation method, you might be modifying a istio ConfigMap in the istio-system namespace. Look for a meshConfig section within that ConfigMap.
Verify Jaeger Deployment: Ensure the Jaeger pods are running in the istio-system namespace (or wherever you installed it).
```
kubectl get pods -n istio-system -l app=jaeger
```
You should see pods like jaeger-query, jaeger-collector, jaeger-agent, etc., in a Running state.
Access Jaeger UI: You can access the Jaeger UI via kubectl port-forward.
```
kubectl port-forward -n istio-system service/jaeger-query 16686:16686
```
Then, open your browser to http://localhost:16686.
Generate Traffic: Make some requests to your services. For example, if you have the frontend service exposed via an Ingress Gateway, access it through that.
View Traces in Jaeger: In the Jaeger UI, select your service (e.g., frontend) and operation (e.g., GET /) and click "Find Traces." You should see the trace for your request, showing the breakdown of time spent in each service.

The most surprising thing about Istio’s tracing is that Envoy itself generates most of the trace data by default. You don’t have to modify your application code to get basic request-level tracing; Istio’s sidecars handle the span creation, propagation, and reporting automatically for HTTP/gRPC traffic.

The exact B3 header format (x-b3-traceid, x-b3-spanid, x-b3-sampled, x-b3-flags, x-b3-parentspanid) is critical. If any intermediary proxy or service strips these headers, the trace will break, and subsequent services won’t be linked into the same trace.

The next step is often integrating application-level spans to provide deeper insights into what your code is doing within a service.