In order to give you better service we use cookies. By continuing to use our website, you agree to the use of cookies as described in our Cookie Policy

Kong Logo
search
Docs
Kong Konnect Platform Konnect Platform Konnect SaaS Kong Gateway (Enterprise) Kong Mesh Plugin Hub
Open Source Kong Gateway (OSS) decK Kubernetes Ingress Controller Insomnia Kuma
Support Community Kong U Demos & Labs
Get Started
Plugin Hub
header icon

TCP Log

Log request and response data to a TCP server.

Configuration Reference

This plugin is compatible with requests with the following protocols:

  • http
  • https
  • grpc
  • grpcs
  • tcp
  • tls
  • udp

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)
Konnect SaaS
Manager

For example, configure this plugin on a service by making the following request:

1
2
3
4
5

$ curl -X POST http://<admin-hostname>:8001/services/<service>/plugins \
    --data "name=tcp-log"  \
    --data "config.host=127.0.0.1" \
    --data "config.port=9999" \
    --data "config.tls=false"

<service> is the id or name of the service that this plugin configuration will target.

First, create a KongPlugin resource:

1
2
3
4
5
6
7
8
9

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <tcp-log-example>
config: 
  host: 127.0.0.1
  port: 9999
  tls: false
plugin: tcp-log

Next, apply the KongPlugin resource to a Service by annotating the Service as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: v1
kind: Service
metadata:
  name: <service>
  labels:
    app: <service>
  annotations:
    konghq.com/plugins: <tcp-log-example>
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: <service>
  selector:
    app: <service>

<service> is the id or name of the service that this plugin configuration will target.

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:

1
2
3
4
5
6
7

plugins:
- name: tcp-log
  service: <service>
  config: 
    host: 127.0.0.1
    port: 9999
    tls: false

<service> is the id or name of the service that this plugin configuration will target.

Configure this plugin on a service:

  1. In Konnect SaaS, select the service on the ServiceHub page.
  2. Scroll down to Versions and select the version.
  3. Scroll down to Plugins and click New Plugin.
  4. Find and select the TCP Log plugin.

  5. Enter the following parameters, updating the default or sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  6. Click Create.

Configure this plugin on a service:

  1. In Kong Manager, select the workspace.
  2. From the Dashboard, scroll down to Services and click View for the service row.
  3. Scroll down to plugins and click Add Plugin.

  4. Find and select the TCP Log plugin.

    Note: If the plugin is greyed out, then it is not available for your product tier. See Kong Gateway tiers.
  5. If the option is available, select Scoped.
  6. Add the service name and ID to the Service field if it is not already prefilled.

  7. Enter the following parameters, updating the default or sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  8. Click Create.

Enabling the plugin on a route

Admin API
Kubernetes
Declarative (YAML)
Konnect SaaS
Manager

For example, configure this plugin on a route with:

1
2
3
4
5

$ curl -X POST http://<admin-hostname>:8001/routes/<route>/plugins \
    --data "name=tcp-log"  \
    --data "config.host=127.0.0.1" \
    --data "config.port=9999" \
    --data "config.tls=false"

<route> is the id or name of the route that this plugin configuration will target.

First, create a KongPlugin resource:

1
2
3
4
5
6
7
8
9

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <tcp-log-example>
config: 
  host: 127.0.0.1
  port: 9999
  tls: false
plugin: tcp-log

Then, apply it to an ingress (Route or Routes) by annotating the ingress as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: networking/v1beta1
kind: Ingress
metadata:
  name: <route>
  annotations:
    kubernetes.io/ingress.class: kong
    konghq.com/plugins: <tcp-log-example>
spec:
  rules:
  - host: examplehostname.com
    http:
      paths:
      - path: /bar
        backend:
          serviceName: echo
          servicePort: 80

<route> is the id or name of the route that this plugin configuration will target.

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:

1
2
3
4
5
6
7

plugins:
- name: tcp-log
  route: <route>
  config: 
    host: 127.0.0.1
    port: 9999
    tls: false

<route> is the id or name of the route that this plugin configuration will target.

Configure this plugin on a route:

  1. In Konnect SaaS, select the service from the ServiceHub page.
  2. Scroll down to Versions and select the version.
  3. Select the route.
  4. Scroll down to Plugins and click Add Plugin.
  5. Find and select the TCP Log plugin.

  6. Enter the following parameters, updating the default or sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  7. Click Create.

Configure this plugin on a route:

  1. In Kong Manager, select the workspace.
  2. From the Dashboard, select Routes in the left navigation.
  3. Click View for the route row.
  4. Scroll down to plugins and click Add Plugin.

  5. Find and select the TCP Log plugin.

    Note: If the plugin is greyed out, then it is not available for your product tier. See Kong Gateway tiers.
  6. If the option is available, select Scoped.
  7. Add the Route ID if it is not already prefilled.

  8. Enter the following parameters, updating the default or sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  9. Click Create.

Enabling the plugin on a consumer

Admin API
Kubernetes
Declarative (YAML)
Manager

For example, configure this plugin on a consumer with:

1
2
3
4
5

$ curl -X POST http://<admin-hostname>:8001/consumers/<consumer>/plugins \
    --data "name=tcp-log"  \
    --data "config.host=127.0.0.1" \
    --data "config.port=9999" \
    --data "config.tls=false"

<consumer> is the id or username of the consumer that this plugin configuration will target.

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:

1
2
3
4
5
6
7
8
9

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <tcp-log-example>
config: 
  host: 127.0.0.1
  port: 9999
  tls: false
plugin: tcp-log

Then, apply it to a consumer by annotating the KongConsumer resource as follows:

1
2
3
4
5
6
7

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: <consumer>
  annotations:
    konghq.com/plugins: <tcp-log-example>
    kubernetes.io/ingress.class: kong

<consumer> is the id or username of the consumer that this plugin configuration will target.

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:

1
2
3
4
5
6
7

plugins:
- name: tcp-log
  consumer: <consumer>
  config: 
    host: 127.0.0.1
    port: 9999
    tls: false

<consumer> is the id or username of the consumer that this plugin configuration will target.

Configure this plugin on a consumer:

  1. In Kong Manager, select the workspace.
  2. From the Dashboard, scroll down to Consumers and click View for the consumer row.
  3. Select the Plugins tab.
  4. Click Add Plugin.

  5. Find and select the TCP Log plugin.

    Note: If the plugin is greyed out, then it is not available for your product tier. See Kong Gateway tiers.
  6. If the option is available, select Global.

  7. Enter the following parameters, updating the default or sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  8. Click Create.

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)
Kong Manager

For example, configure this plugin globally with:

1
2
3
4
5

$ curl -X POST http://<admin-hostname>:8001/plugins/ \
    --data "name=tcp-log"  \
    --data "config.host=127.0.0.1" \
    --data "config.port=9999" \
    --data "config.tls=false"

Create a KongClusterPlugin resource and label it as global:

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
  name: <global-tcp-log>
  annotations:
    kubernetes.io/ingress.class: kong
  labels:
    global: \"true\"
config: 
  host: 127.0.0.1
  port: 9999
  tls: false
plugin: tcp-log

For example, configure this plugin using the plugins: entry in the declarative configuration file:

1
2
3
4
5
6

plugins:
- name: tcp-log
  config: 
    host: 127.0.0.1
    port: 9999
    tls: false

Configure this plugin globally:

  1. In Kong Manager, select the workspace.
  2. From the Dashboard, select Plugins in the left navigation.
  3. Click New Plugin.

  4. Find and select the TCP Log plugin.

    Note: If the plugin is greyed out, then it is not available for your product tier. See Kong Gateway tiers.
  5. If the option is available, set the plugin scope to Global.

  6. Enter the following parameters, updating the default/sample values as needed:

    • Config.Host: 127.0.0.1
    • Config.Port: 9999
    • Config.Tls: false
  7. Click Create.

Parameters

Here's a list of all the parameters which can be used in this plugin's configuration:

Form ParameterDescription
name

Type: string		 The name of the plugin to use, in this case tcp-log.
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.host
required

Type: string

The IP address or host name to send data to.
config.port
required

Type: integer

The port to send data to on the upstream server.
config.timeout
optional

Type: number

Default value: 10000

An optional timeout in milliseconds when sending data to the upstream server.
config.keepalive
optional

Type: number

Default value: 60000

An optional value in milliseconds that defines how long an idle connection lives before being closed.
config.tls
required

Type: boolean

Default value: false

Indicates whether to perform a TLS handshake against the remote server.
config.tls_sni
optional

Type: string

An optional string that defines the SNI (Server Name Indication) hostname to send in the TLS handshake.
config.custom_fields_by_lua
optional

Type: map

A list of key-value pairs, where the key is the name of a log field and the value is a chunk of Lua code, whose return value sets or replaces the log field value.

Log format

Every request is logged separately in a JSON object, separated by a new line \n, with the following format:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

{
  "latencies": {
    "request": 515,
    "kong": 58,
    "proxy": 457
  },
  "service": {
    "host": "httpbin.org",
    "created_at": 1614232642,
    "connect_timeout": 60000,
    "id": "167290ee-c682-4ebf-bdea-e49a3ac5e260",
    "protocol": "http",
    "read_timeout": 60000,
    "port": 80,
    "path": "/anything",
    "updated_at": 1614232642,
    "write_timeout": 60000,
    "retries": 5,
    "ws_id": "54baa5a9-23d6-41e0-9c9a-02434b010b25"
  },
  "request": {
    "querystring": {},
    "size": 138,
    "uri": "/log",
    "url": "http://localhost:8000/log",
    "headers": {
      "host": "localhost:8000",
      "accept-encoding": "gzip, deflate",
      "user-agent": "HTTPie/2.4.0",
      "accept": "*/*",
      "connection": "keep-alive"
    },
    "method": "GET"
  },
  "tries": [
    {
      "balancer_latency": 0,
      "port": 80,
      "balancer_start": 1614232668399,
      "ip": "18.211.130.98"
    }
  ],
  "client_ip": "192.168.144.1",
  "workspace": "54baa5a9-23d6-41e0-9c9a-02434b010b25",
  "upstream_uri": "/anything",
  "response": {
    "headers": {
      "content-type": "application/json",
      "date": "Thu, 25 Feb 2021 05:57:48 GMT",
      "connection": "close",
      "access-control-allow-credentials": "true",
      "content-length": "503",
      "server": "gunicorn/19.9.0",
      "via": "kong/2.2.1.0-enterprise-edition",
      "x-kong-proxy-latency": "57",
      "x-kong-upstream-latency": "457",
      "access-control-allow-origin": "*"
    },
    "status": 200,
    "size": 827
  },
  "route": {
    "id": "78f79740-c410-4fd9-a998-d0a60a99dc9b",
    "paths": [
      "/log"
    ],
    "protocols": [
      "http"
    ],
    "strip_path": true,
    "created_at": 1614232648,
    "ws_id": "54baa5a9-23d6-41e0-9c9a-02434b010b25",
    "request_buffering": true,
    "updated_at": 1614232648,
    "preserve_host": false,
    "regex_priority": 0,
    "response_buffering": true,
    "https_redirect_status_code": 426,
    "path_handling": "v0",
    "service": {
      "id": "167290ee-c682-4ebf-bdea-e49a3ac5e260"
    }
  },
  "started_at": 1614232668342
}

JSON object considerations

A few considerations on the JSON object:

  • request contains properties about the request sent by the client.
  • response contains properties about the response sent to the client.
  • tries contains the list of (re)tries (successes and failures) made by the load balancer for this request.
  • route contains Kong Gateway properties about the specific Route requested.
  • service contains Kong Gateway properties about the Service associated with the requested Route.
  • authenticated_entity contains Kong Gateway properties about the authenticated credential (if an authentication plugin has been enabled).
  • workspaces contains Kong Gateway properties of the Workspaces associated with the requested Route. Only in Kong Gateway version >= 0.34.x. For Kong Gateway version >= 2.1.x, there is a ws_id on services and routes that reference the workspace ID.
  • consumer contains the authenticated Consumer (if an authentication plugin has been enabled).
  • latencies contains some data about the latencies involved:
    • proxy is the time it took for the final service to process the request.
    • kong is the internal Kong latency that it took to run all the plugins.
    • request is the time elapsed between the first bytes were read from the client and after the last bytes were sent to the client. Useful for detecting slow clients.
  • client_ip contains the original client IP address.
  • started_at contains the UTC timestamp of when the request has started to be processed.

Log plugins enabled on services and routes contain information about the service or route.

Kong process errors

This logging plugin logs HTTP request and response data, and also supports streams data (TCP, TLS, and UDP).

If you are looking for the Kong process error file (which is the nginx error file), you can find it at the following path:

{prefix}/logs/error.log

Custom Fields by Lua

The custom_fields_by_lua configuration allows for the dynamic modification of log fields using Lua code. Below is an example configuration that removes the existing route field in the logs:

1

curl -i -X POST --url http://kong:8001/plugins ... --data config.custom_fields_by_lua.route="return nil"

Similarly, new fields can be added:

1

curl -i -X POST --url http://kong:8001/plugins ... --data config.custom_fields_by_lua.header="return kong.request.get_header('h1')"

Limitations

Lua code runs in a restricted sandbox environment, whose behavior is governed by the untrusted_lua configuration properties configuration properties.

Sandboxing consists of several limitations in the way the Lua code can be executed, for heightened security.

The following functions are not available because they can be used to abuse the system:

  • string.rep: Can be used to allocate millions of bytes in one operation.
  • {set|get}metatable: Can be used to modify the metatables of global objects (strings, numbers).
  • collectgarbage: Can be abused to kill the performance of other workers.
  • _G: Is the root node which has access to all functions. It is masked by a temporary table.
  • load{file|string}: Is deemed unsafe because it can grant access to the global environment.
  • raw{get|set|equal}: Potentially unsafe because sandboxing relies on some metatable manipulation.
  • string.dump: Can display confidential server information (such as implementation of functions).
  • math.randomseed: Can affect the host system. Kong Gateway already seeds the random number generator properly.
  • All os.* (except os.clock, os.difftime, and os.time). os.execute can significantly alter the host system.
  • io.*: Provides access to the hard drive.
  • dofile|require: Provides access to the hard drive.

The exclusion of require means that plugins must only use PDK functions kong.*. The ngx.* abstraction is also available, but it is not guaranteed to be present in future versions of the plugin.

In addition to the above restrictions:

  • All the provided modules (like string or table) are read-only and can’t be modified.
  • Bytecode execution is disabled.

Further, as code runs in the context of the log phase, only PDK methods that can run in said phase can be used.