# 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).
If Datadog is running within Kubernetes, you can expose the APM agent port to Kuma via Kubernetes service.
# 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: