# Traffic Trace
This policy enables tracing logging to a third party tracing solution.
You must also:
- Add a tracing backend. You specify a tracing backend as a
- Add a TrafficTrace resource. YOu pass the backend to the
Kuma currently supports the following backends:
- Jaeger (opens new window) as the Zipkin collector. The Zipkin examples specify Jaeger, but you can modify for a Zipkin-only deployment.
While most commonly we want all the traces to be sent to the same tracing backend, we can optionally create multiple tracing backends in a
Mesh resource and store traces for different paths of our service traffic in different backends by leveraging Kuma tags. This is especially useful when we want traces to never leave a world region, or a cloud, for example.
# Add Jaeger backend
apiVersion: kuma.io/v1alpha1 kind: Mesh metadata: name: default spec: tracing: defaultBackend: jaeger-collector backends: - name: jaeger-collector type: zipkin sampling: 100.0 conf: url: http://jaeger-collector.kuma-tracing:9411/api/v2/spans
Apply the configuration with
kubectl apply -f [..].
# Add Datadog backend
- Set up the Datadog (opens new window) agent.
- Set up APM (opens new window).
- For Kubernetes, see the datadog documentation for setting up Kubernetes (opens new window).
# Set up in Kuma
defaultBackend property specifies the tracing backend to use if it's not explicitly specified in the
# Add TrafficTrace resource
TrafficTrace resources that specify how to collect traces, and which backend to store them in.
You can also add tags to apply the
TrafficTrace resource only a subset of data plane proxies.
TrafficTrace is a Dataplane policy, so you can specify any of the
Services should also be instrumented to preserve the trace chain across requests made across different services. You can instrument with a language library of your choice, or you can manually pass the following headers: