Loggly

Log request and response data over UDP to Loggly.

Configuration Reference

This plugin is compatible with DB-less mode.

In DB-less mode, you configure Kong Gateway declaratively. Therefore, the Admin API is mostly read-only. The only tasks it can perform are all related to handling the declarative config, including:

• Setting a target's health status in the load balancer
• Validating configurations against schemas
• Uploading the declarative configuration using the /config endpoint

Example plugin configuration

curl -X POST http://{HOST}:8001/services/{SERVICE}/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <loggly-example>
config: 
  key: YOUR_LOGGLY_SERVICE_TOKEN
plugin: loggly

apiVersion: v1
kind: Service
metadata:
  name: {SERVICE}
  labels:
    app: {SERVICE}
  annotations:
    konghq.com/plugins: <loggly-example>
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: {SERVICE}
  selector:
    app: {SERVICE}

plugins:
- name: loggly
  service: {SERVICE}
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

$ curl -X POST http://{HOST}:8001/routes/{ROUTE}/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <loggly-example>
config: 
  key: YOUR_LOGGLY_SERVICE_TOKEN
plugin: loggly

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

plugins:
- name: loggly
  route: <route>
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

$ curl -X POST http://{HOST}:8001/consumers/{CONSUMER}/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: <loggly-example>
config: 
  key: YOUR_LOGGLY_SERVICE_TOKEN
plugin: loggly

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: {CONSUMER}
  annotations:
    konghq.com/plugins: <loggly-example>
    kubernetes.io/ingress.class: kong

plugins:
- name: loggly
  consumer: {CONSUMER}
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

$ curl -X POST http://{HOST}:8001/plugins/ \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
  name: <global-loggly>
  annotations:
    kubernetes.io/ingress.class: kong
  labels:
    global: \"true\"
config: 
  key: YOUR_LOGGLY_SERVICE_TOKEN
plugin: loggly

plugins:
- name: loggly
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

Parameters

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

Log format

Every request is logged to the System log in SYSLOG standard, with the with message component formatted as described below.

Note: Make sure the Syslog daemon is running on the instance and it’s configured with the logging level severity the same as or lower than the set config.log_level for this plugin.

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

{
  "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:

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

Similarly, new fields can be added:

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.

Changelog

2.1.0

• Starting with Kong Gateway 2.7.0.0, if keyring encryption is enabled, the key parameter value will be encrypted.