Skip to main content

​
Availability

​
Overview

Metrics provide aggregated, quantitative data about the performance and behavior of your APIs over time. They offer insights into the overall health of the system. Tyk Gateway supports three ways to export metrics:

​
In-Product Analytics

If you don’t want to set up your own metrics pipeline and dashboard, Tyk Dashboard provides built-in traffic analytics out of the box. This gives you a historical view of API usage, traffic patterns, and response times (including request counts, response time distribution, and error rates), tracked per API and per client key, with no third party observability tools required. This analytics pipeline uses Tyk Pump or Tyk MDCB to aggregate traffic logs from Tyk Gateway and store them in the Dashboard’s analytics storage. You can also use Tyk Pump to export analytics to external backends such as Elasticsearch, InfluxDB, and Kafka.

​
OpenTelemetry Metrics

Tyk Gateway natively exports metrics via the OpenTelemetry Protocol (OTLP), the recommended way to collect Gateway metrics. When enabled, the Gateway pushes standard RED metrics (Rate, Errors, Duration) plus Go runtime and configuration state metrics to any OTLP-compatible backend without requiring extra infrastructure alongside Tyk. For a complete reference, see:
  • Default Metrics: all metrics exported automatically (RED, Go runtime, configuration state)
  • Custom Metrics: defining custom counters and histograms with your own dimensions

​
Supported Backends

The metrics exporter sends data using standard OTLP, so any OTLP-compatible backend works. Some common setups: Via OTel Collector (recommended for self-managed): Route metrics from the OTel Collector to Prometheus, Grafana Mimir, Splunk, or other backends. The Collector also handles batching, retries, and fanout to multiple destinations. Direct OTLP: Send directly to backends that natively accept OTLP, such as:
  • New Relic (otlp.nr-data.net:4317)
  • Dynatrace (via the Dynatrace OTLP endpoint)
  • Grafana Cloud Mimir
  • Any Prometheus-compatible endpoint with remote write

​
Configuration Options

Metrics can be enabled independently; distributed tracing does not need to be configured. To configure distributed tracing alongside metrics, see Distributed Tracing.

​
Enable Metrics

If you only need metrics export, configure the metrics sub-object directly:

​
Traces and metrics together

When both are configured, metrics.endpoint defaults to the traces.endpoint value if not set explicitly:
This is enough to start exporting default Gateway metrics to the same OTLP endpoint configured for traces.

​
Reference

All fields are also documented in the Tyk Gateway Configuration Reference.
Root-level configuration such as opentelemetry.enabled and opentelemetry.endpoint still work for traces but are deprecated. Use opentelemetry.traces.* for new deployments.

​
Cardinality Control

Each unique combination of dimension values creates a separate time series in your metrics backend. For example, a metric with 100 APIs × 5 methods × 10 status codes = 5,000 time series. Adding dimensions that have many possible values (such as user IDs or free-text fields) can create millions of time series, causing high storage costs and potential out-of-memory crashes. The opentelemetry.metrics.cardinality_limit field caps how many unique attribute combinations are tracked per metric instrument:
  • Default limit: 2,000 combinations per instrument
  • When the limit is reached: New attribute combinations are aggregated into an overflow bucket marked with otel.metric.overflow=true
  • Existing time series are not affected; only new combinations are blocked
  • To disable the limit: Set to 0 (not recommended for production)
You can alert on cardinality overflow using this PromQL expression:
This lets you catch runaway cardinality before costs escalate.

​
Tyk Cloud

On Tyk Cloud, metrics export is enabled per environment via the Telemetry settings in the Tyk Cloud UI. A Telemetry entitlement is required; contact your account team if it is not available on your plan. Supported export destinations on Tyk Cloud:
  • New Relic
  • Elastic (Elasticsearch / OpenSearch)
  • Dynatrace
  • Custom OTLP endpoint (any OTLP-compatible backend)
Tyk Cloud exports the default gateway metrics through the telemetry pipeline. Custom metric configuration is not currently self-service on Tyk Cloud; contact Tyk support to request it.

​
Deprecated Backends

​
New Relic (deprecated)

This instrumentation method is deprecated. New Relic users should migrate to the OpenTelemetry metrics exporter with a New Relic OTLP endpoint. The OTel approach provides richer metrics, more dimensions, and does not require a New Relic agent license.
Tyk Gateway has been instrumented for New Relic metrics since v2.5. Add the following to tyk.conf to enable it:

​
StatsD (deprecated)

This instrumentation method is deprecated. We recommend using OpenTelemetry metrics instead, which provides richer metrics and works with any modern observability backend.
Tyk Gateway, Pump, and Dashboard have been instrumented for StatsD monitoring. StatsD is a network daemon that listens for statistics sent over UDP or TCP and forwards aggregates to pluggable backend services.

​
Configuring StatsD

To enable StatsD instrumentation, set the environment variable TYK_INSTRUMENTATION=1 and configure statsd_connection_string in each component’s config file. This field specifies how to connect to the StatsD server (host, port, and optional configuration). You can also set statsd_prefix to a custom value to differentiate metrics between environments (for example, separate prefixes for production and staging).

​
StatsD Keys