This policy enables tracing logging to a third party tracing solution.
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:
Add a tracing backend. You specify a tracing backend as a
Add a TrafficTrace resource. You pass the backend to the
Kong Mesh currently supports the following trace exposition formats:
zipkintraces in this format can be sent to many different tracing backends.
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 (for zipkin and for datadog). For HTTP you can also manually forward the following headers:
Add a tracing backend to the mesh
This assumes you already have a zipkin compatible collector running. If you haven’t, read the observability docs.
This assumes a Datadog agent is configured and running. If you haven’t already check the Datadog observability page.
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 send them to.
backendfield is omitted, the logs will be forwarded into the
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
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
Meshresource and store traces for different paths of our service traffic in different backends by leveraging Kong Mesh tags. This is especially useful when we want traces to never leave a world region, or a cloud, for example.