OpenTelemetry is an open-source observability framework providing a vendor-neutral standard for collecting traces, metrics, and logs. Since Tyk Gateway v5.2, it is the recommended observability approach for Tyk Gateway. Tyk supports all three signals. Traces and metrics are exported natively via the OpenTelemetry Protocol (OTLP) to any compatible backend. Logs are written as structured JSON to stderr and collected by an external agent. No additional components are required alongside Tyk to get started.Documentation Index
Fetch the complete documentation index at: https://tyk.io/docs/llms.txt
Use this file to discover all available pages before exploring further.
Tracing
Distributed tracing gives you an end-to-end view of individual API requests as they flow through Tyk Gateway and into your upstream services. Traces help you pinpoint latency bottlenecks, trace error propagation across services, and understand the full request lifecycle. Tyk generates parent and child spans for each proxied request. For each API, you can optionally enable detailed tracing to produce a span per middleware, giving granular visibility into authentication, rate limiting, transformation, and routing steps. Supported propagation formats: W3C TraceContext (default), B3, and custom or composite header modes for proprietary correlation headers. Supported backends: Datadog, Dynatrace, Jaeger, New Relic, Elastic, and any OTLP-compatible endpoint. For configuration details and vendor-specific integration guides, see Distributed Tracing with Tyk.Metrics
Tyk Gateway natively pushes metrics to any OTLP-compatible backend with a configurable push interval. No sidecar or agent is required alongside the Gateway. When enabled, the Gateway automatically exports three groups of metrics:- Request metrics: Rate, Errors, and Duration (RED) with a three-way latency split: total, Gateway-only, and upstream-only
- Go runtime metrics: Memory usage, goroutine count, and GC health
- Configuration state metrics: Number of APIs and policies loaded, config reload counts and durations
- OpenTelemetry Metrics Configuration: enabling metrics, export config, and cardinality control
- Default Gateway Metrics: all automatically exported metrics and their dimensions
- Custom Metrics: defining your own counters and histograms
Logs
Tyk Gateway writes logs tostdout/stderr in structured JSON format. It does not have a native OTLP log exporter. To ship gateway logs to an observability backend, deploy the OpenTelemetry Collector with the Filelog Receiver. The Collector tails container log files on each Kubernetes node, optionally enriches them with pod and namespace metadata, and forwards them to a backend like Elasticsearch.
For a step-by-step guide, see Collecting Gateway Logs with OTel on Kubernetes.
If you don’t need a full OTel pipeline, Tyk Pump provides built-in API traffic analytics out of the box, with no external collector required.
Resource Attributes
All OTel signals produced by Tyk Gateway include resource attributes: metadata set once at startup that identifies the source instance. Use these to filter and correlate signals across nodes, edge groups, and environments.| Attribute | Always Present | Description |
|---|---|---|
tyk.gw.id / service.instance.id | Yes | Unique ID for this Gateway instance. |
tyk.gw.dataplane | Yes | Whether the Gateway is running in a distributed Data Plane. |
tyk.gw.group.id | No | Data Plane group ID. Populated only for Gateways in distributed Data Planes. |
tyk.gw.tags | No | Segment tags. Populated only when the Gateway is segmented. |
service.name, service.version, host.name, host.arch, host.ip, process.pid) are also included automatically.
All OpenTelemetry configuration options are documented in the Tyk Gateway configuration reference.
Signal Correlation
Tyk’s three signal types (traces, metrics, and logs) are produced independently, but three mechanisms let you correlate them in your observability backend.Trace and Span IDs in Logs
When OpenTelemetry tracing is enabled, Tyk Gateway injects trace context into both log types: Access logs includetrace_id, the W3C trace ID for the request, matching the root span exported to your tracing backend.
trace_id and span_id on all request-scoped entries (middleware execution, errors, debug output):
span_id identifies the exact span active when the log was emitted, so you can navigate from an error log directly to the span in a trace waterfall.
For the full log field reference, see Logging in Tyk.
Trace and span IDs are only present in log entries associated with a sampled request. Non-request-scoped entries (startup, configuration reload, health-checks) and unsampled requests do not carry these fields.
Exemplars in Histogram Metrics
When both OpenTelemetry tracing and metrics are enabled, Tyk Gateway automatically attaches exemplars whenever a histogram is recorded during an active sampled request. An exemplar embeds thetrace_id and span_id of the active request directly inside a histogram bucket, creating a direct link from an aggregated metric to a specific trace.
What this enables: When you see a latency spike on a http.server.request.duration histogram in Grafana, click the exemplar marker on the chart to navigate directly to the offending trace in Jaeger or Tempo, with no manual trace ID search required.
For full setup details, see Exemplars in the default metrics reference.
Resource Attributes Across All Signals
Traces and metrics both carry the same resource attributes set at Gateway startup. The key correlating attribute istyk.gw.id (also exported as service.instance.id), which uniquely identifies the Gateway that produced each signal.
When running multiple Gateway replicas, this lets you filter metrics to a specific instance using tyk.gw.id and find that same Gateway’s traces using the same attribute.
What’s Next
- Getting Started: A hands-on walkthrough spinning up a full observability stack (Loki, Grafana, Tempo, Prometheus) with Tyk Gateway. (Coming soon)
- Best Practices: Production guidance on export topology, cardinality control, trace sampling, and log collection.
- Gateway Observability Playbook: Diagnosing common failures using RED metrics, response flags, and PromQL alert rules.