Traffic Trace

    Tracing is supported over HTTP, HTTP2, and gRPC protocols. You must explicitly specify the protocol for each service and data plane proxy you want to enable tracing for.

    You must also:

    1. . You specify a tracing backend as a Mesh resource property.
    2. . You pass the backend to the resource.

    Kuma currently supports the following trace exposition formats:

    Services still need to be instrumented to preserve the trace chain across requests made across different services.

    You can instrument with a language library of your choice ( and for datadog). For HTTP you can also manually forward the following headers:

    • x-request-id
    • x-b3-traceid
    • x-b3-parentspanid
    • x-b3-spanid
    • x-b3-sampled
    • x-b3-flags

    Apply the configuration with kubectl apply -f [..].

    1. type: Mesh
    2. name: default
    3. tracing:
    4.   defaultBackend: jaeger-collector
    5.   backends:
    6.   - name: jaeger-collector
    7.     type: zipkin
    8.     sampling: 100.0
    10.       url: http://my-jaeger-collector:9411/api/v2/spans # Replace by any zipkin compatible collector address.

    Apply the configuration with kumactl apply -f [..] or with the HTTP API.

    Datadog

    This assumes a Datadog agent is configured and running. If you haven’t already check the Datadog observability page.

    where trace-svc is the name of the Kubernetes Service you specified when you configured the Datadog APM agent.

    Apply the configuration with kubectl apply -f [..].

    1. type: Mesh
    2. name: default
    3. tracing:
    4.   backends:
    5.   - name: datadog-collector
    6.     type: datadog
    7.     sampling: 100.0
    8.     conf:
    9.       address: 127.0.0.1
    10.       port: 8126

    The defaultBackend property specifies the tracing backend to use if it’s not explicitly specified in the resource.

    Add TrafficTrace resource

    Next, create TrafficTrace resources that specify how to collect traces, and which backend to send them to.

    Apply the configuration with kubectl apply -f [..].

    1. type: TrafficTrace
    2. name: trace-all-traffic
    3. mesh: default
    4. selectors:
    5. - match:
    6.     kuma.io/service: '*'
    7.   backend: jaeger-collector # or the name of any backend defined for the mesh

    Apply the configuration with kumactl apply -f [..] or with the HTTP API.

    When backend field is omitted, the logs will be forwarded into the defaultBackend of that Mesh.

    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 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.