Community Plugin: This plugin is developed, tested, and maintained by a third-party contributor.
This Kong plugin is intended for SignalFx users to obtain performance metrics from their Kong deployments for aggregation and reporting via the Smart Agent or the collectd-kong collectd plugin. It works similarly to other Kong logging plugins and provides connection state and request/response count, latency, status, and size metrics available through a /signalfx
Admin API endpoint.
Installation and configuration
See details on https://github.com/signalfx/kong-plugin-signalfx and https://github.com/signalfx/collectd-kong.
Configuration Reference
This plugin is compatible with DB-less mode.
Example plugin configuration
Enable on a service
Enable on a route
Enable on a consumer
Enable globally
The following examples provide some typical configurations for enabling
the signalfx
plugin on a
service.
Admin API
Kubernetes
Declarative (YAML)
Make the following request:
curl -X POST http://localhost:8001/services/SERVICE_NAME|SERVICE_ID/plugins \
--data "name=signalfx"
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: signalfx-example
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
plugin: signalfx
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: signalfx-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: signalfx
service: SERVICE_NAME|SERVICE_ID
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
Replace SERVICE_NAME|SERVICE_ID
with the id
or name
of the service that this plugin configuration will target.
The following examples provide some typical configurations for enabling
the signalfx
plugin on a
route.
Admin API
Kubernetes
Declarative (YAML)
Make the following request:
curl -X POST http://localhost:8001/routes/ROUTE_NAME|ROUTE_ID/plugins \
--data "name=signalfx"
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: signalfx-example
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
plugin: signalfx
Then, apply it to an ingress (route or routes)
by annotating the ingress as follows:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ROUTE_NAME|ROUTE_ID
annotations:
kubernetes.io/ingress.class: kong
konghq.com/plugins: signalfx-example
spec:
rules:
- host: examplehostname.com
http:
paths:
- path: /bar
backend:
service:
name: echo
port:
number: 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: signalfx
route: ROUTE_NAME
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
Replace ROUTE_NAME|ROUTE_ID
with the id
or name
of the route that this plugin configuration
will target.
The following examples provide some typical configurations for enabling
the signalfx
plugin on a
consumer.
Admin API
Kubernetes
Declarative (YAML)
Make the following request:
curl -X POST http://localhost:8001/consumers/CONSUMER_NAME|CONSUMER_ID/plugins \
--data "name=signalfx"
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: signalfx-example
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
plugin: signalfx
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: signalfx-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: signalfx
consumer: CONSUMER_NAME|CONSUMER_ID
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
Replace CONSUMER_NAME|CONSUMER_ID
with the id
or name
of the consumer that this plugin configuration will target.
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 signalfx
plugin globally.
Admin API
Kubernetes
Declarative (YAML)
Make the following request:
curl -X POST http://localhost:8001/plugins/ \
--data "name=signalfx"
Create a KongClusterPlugin
resource and label it as global:
apiVersion: configuration.konghq.com/v1
kind: KongClusterPlugin
metadata:
name: <global-signalfx>
annotations:
kubernetes.io/ingress.class: kong
labels:
global: \"true\"
config:
<optional_parameter>: <value>
plugin: signalfx
Add a plugins
entry in the declarative
configuration file:
plugins:
- name: signalfx
config:
EXAMPLE_PARAMETER: EXAMPLE_VALUE
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 signalfx . |
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. |
api_id
Type: string |
The ID of the API the plugin targets.
Note: The API Entity is deprecated in favor of Services since CE 0.13.0 and EE 0.32. |
config.aggregate_by_http_method
required
Default value: true
|
By default, metrics for each Service/API-fielded request cycle will be aggregated by a context determined partially by the request’s HTTP method and by its response’s status code.
If you are monitoring a large infrastructure with hundreds of routes, grouping by HTTP method can be too granular or costly for performant /signalfx requests on a 1s interval, depending on the server resources.
This context grouping can be disabled with the boolean configuration option aggregate_by_http_method .
|