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

Are you a Kong Gateway user? We'd love your feedback. Take the Survey

Kong Logo
  • Get Started
  • Products
    • kong-enterprise Kong Enterprise
      • Kong Enterprise

        End-to-end connectivity platform

      • Kong Mesh

        Universal service mesh

      • Kong Studio

        Empower your developers

      • Dev Portal

        Accelerate innovation

      • Kong Manager

        Manage all your services

      • Kong Immunity

        Autonomously identify issues

      • Kong for Kubernetes

        Native Kubernetes Ingress Controller

      • Enterprise Plugins

        Instantly implement policies

      • Kong Vitals

        Monitor your Kong Enterprise

      • Get Started
    • Built on an Open-source Foundation
      • kong-gateway Kong Gateway

        API Gateway

      • kuma Kuma

        Service Mesh

      • insomnia Insomnia

        API Design and Testing

      • Install
    • Kubernetes & Subscriptions
      • Kubernetes Ingress Controller

        Ingress and CRDs

      • Subscriptions

        Kong Gateway and Enterprise features

  • Solutions
    • Use Cases
      • Decentralize Apps and Services

        Accelerate your journey into microservices

      • Secure and Govern APIs

        Empower teams to provide security, governance and compliance

      • Create a Developer Platform

        Rapidly design, publish and consume APIs and services

    • Deployment Patterns
      • API Gateway

        Take control of your microservices with the world’s most popular API gateway

      • Kubernetes

        Own your Kubernetes cluster by using Kong as an Ingress Controller

      • Service Mesh

        Build, secure and observe your modern Service Mesh

  • Plugins
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Docs
    • Documentation
      • Kong Gateway
      • Kong Enterprise
      • Kong Mesh
      • Kong Studio
      • Plugins Hub
  • Resources
    • Learning
      • eBooks
      • Webinars
      • Briefs
      • Blog
    • Community
      • Community
      • Kong Nation
      • Kong Summit
      • GitHub
    • Support
      • Enterprise Support Portal
      • FAQS
      • Kong Professional Services
      • Kong University
  • Company
    • About
    • Customers
    • Investors
    • Careers
    • Partners
    • Press
    • Contact
  • Get Started
header icon

Loggly

  • 1.0-x (latest)
  • 0.1-x
  • Back to Kong Plugin Hub
  • githubEdit this page
  • report-issueReport an issue
  • Configuration Reference
    • Enabling the plugin on a Service
    • Enabling the plugin on a Route
    • Enabling the plugin on a Consumer
    • Enabling the plugin globally
    • Parameters
  • Log Format
  • Kong Process Errors
About this Plugin
Made by
Categories
  • Logging
DB-less compatible? Yes (Kong Gateway only)
Bundled with...
    Kong Enterprise
  • 2.2.x
  • 2.1.x
  • 1.5.x
  • 1.3-x
  • 0.36-x
  • 0.35-x
  • 0.34-x
  • 0.33-x
  • 0.32-x
  • 0.31-x
    Kong Community
  • 2.2.x
  • 2.1.x
  • 2.0.x
  • 1.5.x
  • 1.4.x
  • 1.3.x
  • 1.2.x
  • 1.1.x
  • 1.0.x
  • 0.14.x
  • 0.13.x
  • 0.12.x
  • 0.11.x
  • 0.10.x
  • 0.9.x
  • 0.8.x
  • 0.7.x
  • 0.6.x

Log request and response data over UDP to Loggly.

Configuration Reference

You can configure this plugin using the Kong Admin API or through declarative configuration, which involves directly editing the Kong configuration file.

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 does not have an Admin API. If using this mode, configure the plugin using declarative configuration.

Enabling the plugin on a Service

Kong 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=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

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>
  labels:
    app: <service>
  annotations:
    konghq.com/plugins: <loggly-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: loggly
  service: <service>
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

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

Enabling the plugin on a Route

Kong 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=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

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>
  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
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: loggly
  route: <route>
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

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

Enabling the plugin on a Consumer

Kong 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=loggly"  \
    --data "config.key=YOUR_LOGGLY_SERVICE_TOKEN"

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>
  annotations:
    konghq.com/plugins: <loggly-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: loggly
  consumer: <consumer>
  config: 
    key: YOUR_LOGGLY_SERVICE_TOKEN

<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.

Kong Admin API
Kubernetes
Declarative (YAML)

For example, configure this plugin globally with:

$ curl -X POST http://<admin-hostname>: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

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

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:

Form ParameterDescription
name

Type: string
The name of the plugin to use, in this case loggly.
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
optional

Default value: logs-01.loggly.com

The IP address or host name of Loggly server

config.port
optional

Default value: 514

The UDP port to send data to on the Loggly server

config.key
required

Loggly customer token.

config.tags
optional

Default value: kong

An optional list of tags to support segmentation & filtering of logs.

config.timeout
optional

Default value: 10000

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

config.successful_severity
optional

Default value: info

An optional logging severity assigned to the all successful requests with response status code 400 .

config.client_errors_severity
optional

Default value: info

An optional logging severity assigned to the all failed requests with response status code 400 or higher but less than 500.

config.server_errors_severity
optional

Default value: info

An optional logging severity assigned to the all failed requests with response status code 500 or higher.

config.log_level
optional

Default value: info

An optional logging severity, any request with equal or higher severity will be logged to Loggly.

Log Format

Every request will be transmitted to Loggly in SYSLOG standard, with message component in the following format:

{
    "request": {
        "method": "GET",
        "uri": "/get",
        "url": "http://httpbin.org:8000/get",
        "size": "75",
        "querystring": {},
        "headers": {
            "accept": "*/*",
            "host": "httpbin.org",
            "user-agent": "curl/7.37.1"
        }
    },
    "upstream_uri": "/",
    "response": {
        "status": 200,
        "size": "434",
        "headers": {
            "Content-Length": "197",
            "via": "kong/0.3.0",
            "Connection": "close",
            "access-control-allow-credentials": "true",
            "Content-Type": "application/json",
            "server": "nginx",
            "access-control-allow-origin": "*"
        }
    },
    "tries": [
        {
            "state": "next",
            "code": 502,
            "ip": "127.0.0.1",
            "port": 8000
        },
        {
            "ip": "127.0.0.1",
            "port": 8000
        }
    ],
    "authenticated_entity": {
        "consumer_id": "80f74eef-31b8-45d5-c525-ae532297ea8e",
        "id": "eaa330c0-4cff-47f5-c79e-b2e4f355207e"
    },
    "route": {
        "created_at": 1521555129,
        "hosts": null,
        "id": "75818c5f-202d-4b82-a553-6a46e7c9a19e",
        "methods": null,
        "paths": [
            "/example-path"
        ],
        "preserve_host": false,
        "protocols": [
            "http",
            "https"
        ],
        "regex_priority": 0,
        "service": {
            "id": "0590139e-7481-466c-bcdf-929adcaaf804"
        },
        "strip_path": true,
        "updated_at": 1521555129
    },
    "service": {
        "connect_timeout": 60000,
        "created_at": 1521554518,
        "host": "example.com",
        "id": "0590139e-7481-466c-bcdf-929adcaaf804",
        "name": "myservice",
        "path": "/",
        "port": 80,
        "protocol": "http",
        "read_timeout": 60000,
        "retries": 5,
        "updated_at": 1521554518,
        "write_timeout": 60000
    },
    "workspaces": [
        {
            "id":"b7cac81a-05dc-41f5-b6dc-b87e29b6c3a3",
            "name": "default"
        }
    ],
    "consumer": {
        "username": "demo",
        "created_at": 1491847011000,
        "id": "35b03bfc-7a5b-4a23-a594-aa350c585fa8"
    },
    "latencies": {
        "proxy": 1430,
        "kong": 9,
        "request": 1921
    },
    "client_ip": "127.0.0.1",
    "started_at": 1433209822425
}

A few considerations on the above 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 properties about the specific Route requested
  • service contains Kong properties about the Service associated with the requested Route
  • authenticated_entity contains Kong properties about the authenticated credential (if an authentication plugin has been enabled)
  • workspaces contains Kong properties of the Workspaces associated with the requested Route. Only in Kong Enterprise version >= 0.34.
  • 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 API transaction has started to be processed.

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

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Gateway
    • Kong Enterprise
    • Get Started
    • Subscriptions
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2021