Correlate requests and responses using a unique ID transmitted over an HTTP header.
Configuration Reference
This plugin is compatible with requests with the following protocols:
This plugin is compatible with DB-less mode.
In DB-less mode, Kong Gateway does not have an Admin API. If using this
mode, configure the plugin using declarative configuration.
Enabling the plugin on a Service
Admin API
Kubernetes
Declarative (YAML)
For example, configure this plugin on a Service by
making the following request:
$ curl -X POST http://<admin-hostname>:8001/services/<service>/plugins \
--data "name=correlation-id" \
--data "config.header_name=Kong-Request-ID" \
--data "config.generator=uuid#counter" \
--data "config.echo_downstream=false"
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: <correlation-id-example>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
plugin: correlation-id
Next, apply the KongPlugin resource to a
Service by annotating the Service as
follows:
apiVersion: v1
kind: Service
metadata:
name: <service>
labels:
app: <service>
annotations:
konghq.com/plugins: <correlation-id-example>
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: <service>
selector:
app: <service>
Note: The KongPlugin resource only needs to be defined once
and can be applied to any Service, Consumer, or Route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
For example, configure this plugin on a Service by
adding this section to your declarative configuration file:
plugins:
- name: correlation-id
service: <service>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
<service>
is the id
or name
of the Service that this plugin
configuration will target.
Enabling the plugin on a Route
Admin API
Kubernetes
Declarative (YAML)
For example, configure this plugin on a Route with:
$ curl -X POST http://<admin-hostname>:8001/routes/<route>/plugins \
--data "name=correlation-id" \
--data "config.header_name=Kong-Request-ID" \
--data "config.generator=uuid#counter" \
--data "config.echo_downstream=false"
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: <correlation-id-example>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
plugin: correlation-id
Then, apply it to an ingress (Route or Routes)
by annotating the ingress as follows:
apiVersion: networking/v1beta1
kind: Ingress
metadata:
name: <route>
annotations:
kubernetes.io/ingress.class: kong
konghq.com/plugins: <correlation-id-example>
spec:
rules:
- host: examplehostname.com
http:
paths:
- path: /bar
backend:
serviceName: echo
servicePort: 80
Note: The KongPlugin resource only needs to be defined once
and can be applied to any Service, Consumer, or Route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
For example, configure this plugin on a Route by
adding this section to your declarative configuration file:
plugins:
- name: correlation-id
route: <route>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
<route>
is the id
or name
of the Route that this plugin configuration
will target.
Enabling the plugin on a Consumer
Admin API
Kubernetes
Declarative (YAML)
For example, configure this plugin on a Consumer with:
$ curl -X POST http://<admin-hostname>:8001/consumers/<consumer>/plugins \
--data "name=correlation-id" \
--data "config.header_name=Kong-Request-ID" \
--data "config.generator=uuid#counter" \
--data "config.echo_downstream=false"
You can combine consumer.id
, service.id
, or route.id
in the same request, to further narrow the scope of the plugin.
First, create a KongPlugin
resource:
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: <correlation-id-example>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
plugin: correlation-id
Then, apply it to a Consumer by
annotating the KongConsumer resource as follows:
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
name: <consumer>
annotations:
konghq.com/plugins: <correlation-id-example>
kubernetes.io/ingress.class: kong
Note: The KongPlugin resource only needs to be defined once
and can be applied to any Service, Consumer, or Route in the namespace. If you
want the plugin to be available cluster-wide, create the resource as a
KongClusterPlugin
instead of KongPlugin
.
For example, configure this plugin on a Consumer by
adding this section to your declarative configuration file:
plugins:
- name: correlation-id
consumer: <consumer>
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
<consumer>
is the id
or username
of the Consumer that this plugin
configuration will target.
Enabling the plugin globally
A plugin which is not associated to any Service, Route, or Consumer is
considered global, and will be run on every request. Read the
Plugin Reference and the Plugin Precedence
sections for more information.
Admin API
Kubernetes
Declarative (YAML)
For example, configure this plugin globally with:
$ curl -X POST http://<admin-hostname>:8001/plugins/ \
--data "name=correlation-id" \
--data "config.header_name=Kong-Request-ID" \
--data "config.generator=uuid#counter" \
--data "config.echo_downstream=false"
Create a KongClusterPlugin
resource and label it as global:
apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
name: <global-correlation-id>
annotations:
kubernetes.io/ingress.class: kong
labels:
global: \"true\"
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
plugin: correlation-id
For example, configure this plugin using the plugins:
entry in the declarative
configuration file:
plugins:
- name: correlation-id
config:
header_name: Kong-Request-ID
generator: uuid#counter
echo_downstream: false
Parameters
Here's a list of all the parameters which can be used in this plugin's configuration:
Form Parameter | Description |
name
Type: string |
The name of the plugin to use, in this case correlation-id . |
service.id
Type: string |
The ID of the Service the plugin targets. |
route.id
Type: string |
The ID of the Route the plugin targets. |
consumer.id
Type: string |
The ID of the Consumer the plugin targets. |
enabled
Type: boolean
Default value: true |
Whether this plugin will be applied. |
config.header_name
optional
Default value: Kong-Request-ID
|
The HTTP header name to use for the correlation ID.
|
config.generator
optional
Default value: uuid#counter
|
The generator to use for the correlation ID. Accepted values are uuid , uuid#counter and tracker See Generators.
|
config.echo_downstream
optional
Default value: false
|
Whether to echo the header back to downstream (the client).
|
How it works
When enabled, this plugin will add a new header to all of the requests processed by Kong. This header bears the name configured in config.header_name
, and a unique value generated according to config.generator
.
This header is always added to calls to your upstream services, and optionally echoed back to your clients according to the config.echo_downstream
setting.
If a header bearing the same name is already present in the client request, it is honored and this plugin will not temper with it.
Generators
uuid
Format:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Using this format, a UUID is generated in its hexadecimal form for each request.
uuid#counter
Format:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx#counter
In this format, a single UUID is generated on a per-worker basis, and further requests simply append a counter to the UUID after a #
character. The counter
value starts at 0
for each worker, and gets incremented independently of the others.
This format provides a better performance, but might be harder to store or process for analyzing (due to its format and low cardinality).
tracker
Format:
ip-port-pid-connection-connection_requests-timestamp
In this format, the correlation id contains more practical implications for each request.
The following is a detailed description of the field
form parameter |
description |
ip |
an address of the server which accepted a request |
port |
port of the server which accepted a request |
pid |
pid of the nginx worker process |
connection |
connection serial number |
connection_requests |
current number of requests made through a connection |
timestamp |
a floating-point number for the elapsed time in seconds (including milliseconds as the decimal part) from the epoch for the current time stamp from the nginx cached time |
FAQ
Can I see my correlation ids in my Kong logs?
The correlation id will not show up in the Nginx access or error logs. As such, we suggest you use this plugin alongside one of the Logging plugins, or store this id on your backend-side.