Skip to main content
This page describes forwarding traffic logs to external tools using Tyk Pump. OpenTelemetry tracing is an alternative for new integrations: it exports per-request span data directly from Tyk Gateway, without the Redis and Tyk Pump hop. It’s not a like-for-like replacement, though: OTel spans use a different schema from Tyk’s traffic log fields, and not every destination on this page has an OTel exporter. Use this page if you need Tyk’s traffic log format, a destination without OTel support, or already have an existing deployment built around Tyk Pump.
Tyk Pump can forward traffic logs to a range of external tools, each its own pump type, in parallel with, or instead of, the pumps that populate Tyk Dashboard Analytics. Every pump on this page is declared the same way, under the pumps object in pump.conf, and every pump also accepts the common pump settings (filters, timeout, and so on) in addition to its own fields shown below. Every pump on this page forwards each traffic log largely as-is, mapped into that destination’s native format.
None of the pumps on this page ever receive aggregated analytics, whichever way you deploy them. Aggregation only ever feeds Tyk Dashboard’s Traffic Analytics graphs; see How Aggregation Works. External sinks only ever see individual traffic logs.
This page covers every External Data Sink pump. StatsD, DogStatsD, and Prometheus are metrics pumps, not sink pumps, so they’re covered on Metrics Pumps instead; see the pump type catalog for the full breakdown.

Combined vs Distributed Deployments

In a combined control and data plane, these pumps work exactly like the ones that feed Tyk Dashboard: Tyk Pump reads from the shared Redis and writes to each configured destination in parallel. In a distributed deployment, with separate control and data planes connected via Tyk MDCB, you have two options, and they’re not equivalent:
  • Run the sink pump directly on the data plane, alongside the Hybrid Pump, reading from the same local Redis. This is the simpler option.
  • Run the sink pump on the control plane, as a Control Plane Pump, receiving traffic logs the Hybrid Pump has forwarded via Tyk MDCB. This requires forward_analytics_to_pump: true. See Data Plane Pump for that mechanism in full.

CSV

Tyk Pump can create or append to a CSV file to track API traffic logs. In addition to the common pump settings, the csv pump accepts the following meta field:
Limitations:
  • Writes one file per hour, named YYYY-Month-DD-HH.csv, inside csv_dir.
  • Every traffic log field is written; there’s no fields filtering support.

Stdout

Writes traffic logs to standard output as JSON, useful for sidecar log collectors such as the Datadog logging agent in Kubernetes. In addition to the common pump settings, the stdout pump accepts the following meta fields:

Syslog

Sends traffic logs to a syslog daemon. In addition to the common pump settings, the syslog pump accepts the following meta fields:
Limitations:
  • If working with FluentD, use a FluentD parser matching your OS so FluentD reads the logs correctly.

Open Source Data Sinks

These sinks are open source software you run and manage yourself.

Elasticsearch

Elasticsearch is a highly scalable, distributed search engine for large volumes of data. In addition to the common pump settings, the elasticsearch pump accepts the following meta fields:
ssl_insecure_skip_verify disables all TLS certificate validation for this connection. Only use it for local development or testing, never in production, it exposes the connection to man-in-the-middle attacks.

Graylog

Sends traffic logs to Graylog. In addition to the common pump settings, the graylog pump accepts the following meta fields:

InfluxDB

Tyk Pump can write traffic logs to InfluxDB 1.x. For InfluxDB 2.x, use Influx2 below instead. In addition to the common pump settings, the influx pump accepts the following meta fields:
Limitations:
  • Points are written to a fixed measurement, analytics; this isn’t configurable.

Influx2

For InfluxDB 1.x, use InfluxDB above instead. Uses the official Go client library for InfluxDB 2.x. In addition to the common pump settings, the influx2 pump accepts the following meta fields:

Kafka

Publishes traffic logs to a Kafka topic. In addition to the common pump settings, the kafka pump accepts the following meta fields:
ssl_insecure_skip_verify disables all TLS certificate validation for this connection. Only use it for local development or testing, never in production, it exposes the connection to man-in-the-middle attacks.

Commercial and SaaS Data Sinks

These sinks are commercial products or hosted SaaS platforms.

Logz.io

Logz.io is a cloud-based log management and analytics platform built on Elasticsearch, Logstash, and Kibana. In addition to the common pump settings, the logzio pump accepts the following meta fields:

Moesif

Moesif provides API analytics and usage-based billing. With the Moesif pump, traffic logs are sent to Moesif asynchronously, including payloads, and Moesif collects the authenticated user (Alias ID or OAuth ID) to identify customers. In addition to the common pump settings, the moesif pump accepts the following meta fields:
Limitations:

Resurface.io

Resurface captures every API call as a durable transaction in a purpose-built data lake, for attack and failure triage, root cause analysis, and usage monitoring. In addition to the common pump settings, the resurfaceio pump accepts the following meta fields:
Limitations:

Segment

Tyk Pump can send traffic logs to Segment as Track events. In addition to the common pump settings, the segment pump accepts the following meta field:
Limitations:
  • Every traffic log field is sent as the event’s properties; there’s no fields/tags filtering support.
  • Each event is named Hit, with AnonymousId set to the request’s API key.

Splunk

Sends traffic logs to Splunk via its HTTP Event Collector (HEC). In addition to the common pump settings, the splunk pump accepts the following meta fields:
ssl_insecure_skip_verify disables all TLS certificate validation for this connection. Only use it for local development or testing, never in production, it exposes the connection to man-in-the-middle attacks.

AWS Pumps

Timestream, SQS, and Kinesis all authenticate using the official AWS Go SDK’s default credential chain: environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, or AWS_WEB_IDENTITY_TOKEN_FILE), the shared credentials file under .aws in your home directory, an ECS task role, or an EC2 instance role, in that order. See the AWS SDK documentation for details. Without credentials from one of these sources, the pump can’t connect. The SQS pump additionally accepts explicit aws_key/aws_secret/aws_token fields in its own config, which override the default credential chain when set.

Kinesis

Publishes traffic logs to an Amazon Kinesis stream. In addition to the common pump settings, the kinesis pump accepts the following meta fields:

SQS

Publishes traffic logs to an Amazon SQS queue. In addition to the common pump settings, the sqs pump accepts the following meta fields:

Timestream

Writes traffic logs to Amazon Timestream. In addition to the common pump settings, the timestream pump accepts the following meta fields: