Skip to content
Kong Summit 2022: Where API Innovation Runs Wild  —Learn More →
|
search
Plugin Hub
header icon

Loggly

You are browsing documentation for an outdated plugin version. See the latest documentation here.

Log request and response data over UDP to Loggly.

Configuration Reference

This plugin is compatible with DB-less mode.

Example plugin configuration

The following examples provide some typical configurations for enabling the loggly plugin on a service.

Make the following request:

curl -X POST http://localhost:8001/services/SERVICE_NAME|SERVICE_ID/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

Replace SERVICE_NAME|SERVICE_ID with the id or name of the service that this plugin configuration will target.

First, create a KongPlugin resource:

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

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

apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME|SERVICE_ID
  labels:
    app: SERVICE_NAME|SERVICE_ID
  annotations:
    konghq.com/plugins: loggly-example
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: SERVICE_NAME|SERVICE_ID
  selector:
    app: SERVICE_NAME|SERVICE_ID

Replace SERVICE_NAME|SERVICE_ID with 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.

Add this section to your declarative configuration file:

plugins:
- name: loggly
  service: SERVICE_NAME|SERVICE_ID
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

Replace SERVICE_NAME|SERVICE_ID with the id or name of the service that this plugin configuration will target.

You can configure this plugin through the Konnect UI.

From the servicehub icon Service Hub, select a service version, then set up the plugin:

  1. In the Plugins section, click Add Plugin.
  2. Find and select the Loggly plugin.

  3. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  4. Click Create.

You can configure this plugin through the Kong Manager UI.

  1. In Kong Manager, select the workspace.
  2. From the Services section, click View for the service row.
  3. From the plugin section, click Add Plugin.
  4. Find and select the Loggly plugin.
  5. If the option is available, select Scoped.
  6. Add the service name and ID to the Service field if it is not already pre-filled.

  7. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  8. Click Create.

The following examples provide some typical configurations for enabling the loggly plugin on a route.

Make the following request:

$ curl -X POST http://localhost:8001/routes/ROUTE_NAME|ROUTE_ID/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

Replace ROUTE_NAME|ROUTE_ID with the id or name of the route that this plugin configuration will target.

First, create a KongPlugin resource:

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

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

apiVersion: networking/v1beta1
kind: Ingress
metadata:
  name: ROUTE_NAME|ROUTE_ID
  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

Replace ROUTE_NAME|ROUTE_ID with 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.

Add this section to your declarative configuration file:

plugins:
- name: loggly
  route: ROUTE_NAME
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

Replace ROUTE_NAME|ROUTE_ID with the id or name of the route that this plugin configuration will target.

You can configure this plugin through the Konnect UI.

From the servicehub icon Service Hub, select a service version, then set up the plugin:

  1. Select a route.
  2. In the Plugins section, click Add Plugin.
  3. Find and select the Loggly plugin.

  4. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  5. Click Create.

You can configure this plugin through the Kong Manager UI.

  1. In Kong Manager, select the workspace.
  2. Open Routes from the menu, then click View for the route row.
  3. From the plugin section, click Add Plugin.
  4. Find and select the Loggly plugin.
  5. If the option is available, select Scoped.
  6. Add the route ID if it is not already prefilled.

  7. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  8. Click Create.

The following examples provide some typical configurations for enabling the loggly plugin on a consumer.

Make the following request:

$ curl -X POST http://localhost:8001/consumers/CONSUMER_NAME|CONSUMER_ID/plugins \
    --data "name=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

Replace CONSUMER_NAME|CONSUMER_ID with the id or name 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:

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

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

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: CONSUMER_NAME|CONSUMER_ID
  annotations:
    konghq.com/plugins: loggly-example
    kubernetes.io/ingress.class: kong

Replace CONSUMER_NAME|CONSUMER_ID with the id or name 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.

Add this section to your declarative configuration file:

plugins:
- name: loggly
  consumer: CONSUMER_NAME|CONSUMER_ID
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

Replace CONSUMER_NAME|CONSUMER_ID with the id or name of the consumer that this plugin configuration will target.

You can configure this plugin through the Kong Manager UI.

  1. In Kong Manager, select the workspace.
  2. From the Consumers section, click View for the consumer row.
  3. Select the Plugins tab, then click Add Plugin.
  4. Find and select the Loggly plugin.
  5. If the option is available, select Scoped.
  6. Add the consumer ID if it is not already prefilled.

  7. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  8. Click Create.

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.

The following examples provide some typical configurations for enabling the loggly plugin globally.

Make the following request:

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

Create a KongClusterPlugin resource and label it as global:

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

Add a plugins entry in the declarative configuration file:

plugins:
- name: loggly
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

You can configure this plugin through the Kong Manager UI.

  1. In Kong Manager, select the workspace.
  2. Open Plugins from the menu, then click New Plugin.
  3. Find and select the Loggly plugin.
  4. If the option is available, set the plugin scope to Global.

  5. Configure the plugin’s parameters.

    You can test out the plugin with the following sample configuration:

    • Config.Key: YOUR_LOGGLY_SERVICE_TOKEN
  6. Click Create.

Parameters

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

Form Parameter Description
name
required

Type: string		 The name of the plugin, in this case loggly.
service.name or service.id

Type: string		 The name or ID of the service the plugin targets.

Set one of these parameters if adding the plugin to a service through the top-level /plugins endpoint.

Not required if using /services/SERVICE_NAME|SERVICE_ID/plugins.
route.name or route.id

Type: string		 The name or ID of the route the plugin targets.

Set one of these parameters if adding the plugin to a route through the top-level /plugins endpoint.

Not required if using /routes/ROUTE_NAME|ROUTE_ID/plugins.
consumer.name or consumer.id

Type: string		 The name or ID of the consumer the plugin targets.

Set one of these parameters if adding the plugin to a consumer through the top-level /plugins endpoint.

Not required if using /consumers/CONSUMER_NAME|CONSUMER_ID/plugins.
enabled

Type: boolean

Default value: true		 Whether this plugin will be applied.
config.host
optional

Type: string

Default value: logs-01.loggly.com

The IP address or hostname of Loggly server.
config.port
optional

Type: integer

Default value: 514

The UDP port to send data to on the Loggly server.
config.key
required

Type: string

Loggly customer token.
config.tags
optional

Type: set of string elements

Default value: kong

An optional list of tags to support segmentation and filtering of logs.
config.timeout
optional

Type: number

Default value: 10000

An optional timeout in milliseconds when sending data to the Loggly server.
config.successful_severity
optional

Type: string

Default value: info

An optional logging severity assigned to all the successful requests with a response status code 400. Available options: debug, info, notice, warning, err, crit, alert, emerg.
config.client_errors_severity
optional

Type: string

Default value: info

An optional logging severity assigned to all the failed requests with a response status code 400 or higher but less than 500. Available options: debug, info, notice, warning, err, crit, alert, emerg.
config.server_errors_severity
optional

Type: string

Default value: info

An optional logging severity assigned to all the failed requests with response status code 500 or higher. Available options: debug, info, notice, warning, err, crit, alert, emerg.
config.log_level
optional

Type: string

Default value: info

An optional logging severity, any request with equal or higher severity will be logged to Loggly. Available options: debug, info, notice, warning, err, crit, alert, emerg.

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