Kong API Gateway Monitoring with Vigilmon

Kong is one of the most widely deployed open-source API gateways. It sits in front of your backend services — routing traffic, enforcing auth, rate limiting, and transforming requests. When Kong goes down, every service behind it becomes unreachable simultaneously. When an upstream fails silently, Kong keeps routing to it and your API returns errors.

This guide covers how to monitor Kong and its upstreams with Vigilmon.

Understanding Kong's Health Endpoints

Kong exposes two sets of health information:

Admin API (port 8001 by default)

• GET http://localhost:8001/ — Kong info and status
• GET http://localhost:8001/status — detailed node status including memory and connections
• GET http://localhost:8001/upstreams/{upstream}/health — health of a specific upstream and its targets

Proxy port (8000 by default)

• Health is implicit — if the proxy port is accepting connections and routing correctly, Kong is running

For external monitoring, you typically can't hit the Admin API directly (it's internal). Instead, you either:

1. Expose a lightweight health endpoint through the proxy
2. Run a Vigilmon agent on your internal network
3. Use a dedicated status route protected by a key-auth plugin

Setting Up a Kong Health Route for External Monitoring

The cleanest approach is a dedicated route in Kong that returns a health response, proxied through the public port:

Step 1: Create a health service and route

# Create a service pointing to your health backend
curl -i -X POST http://localhost:8001/services \
  --data name=health-check \
  --data url=http://localhost:8001/status

# Create a route for it
curl -i -X POST http://localhost:8001/services/health-check/routes \
  --data 'paths[]=/health' \
  --data name=health-route

Now GET https://api.example.com/health routes through Kong to the admin status endpoint, returning:

{
  "server": {
    "connections_active": 1,
    "connections_reading": 0,
    "connections_writing": 1,
    "connections_waiting": 0,
    "connections_handled": 12,
    "connections_accepted": 12,
    "total_requests": 45
  },
  "database": {
    "reachable": true
  }
}

Step 2: Secure the health route

Don't expose the admin status payload publicly without auth. Add a key-auth plugin to the route:

curl -X POST http://localhost:8001/routes/health-route/plugins \
  --data name=key-auth \
  --data config.key_names=x-health-token

# Create a consumer and API key
curl -X POST http://localhost:8001/consumers \
  --data username=vigilmon-monitor

curl -X POST http://localhost:8001/consumers/vigilmon-monitor/key-auth \
  --data key=your-secret-monitor-key

In Vigilmon, add the custom header X-Health-Token: your-secret-monitor-key.

Vigilmon Monitor Configuration

Monitor 1: Kong Gateway Availability

1. Log in to Vigilmon → Monitors → New Monitor
2. Type: HTTP
3. Method: GET
4. URL: https://api.example.com/health
5. Interval: 1 minute
6. Custom headers: X-Health-Token: your-secret-monitor-key
7. Keyword check: "reachable":true
8. Save

This verifies:

• Kong's proxy port is accepting connections
• Kong is routing requests
• Kong's database (Postgres or Cassandra) is reachable

Monitor 2: Kong Admin API (Internal Network)

If you run a Vigilmon agent inside your network or use a private monitoring node:

1. URL: http://localhost:8001/status
2. Type: HTTP
3. Keyword check: "reachable":true
4. Interval: 1 minute

Monitoring Kong Upstreams

Kong's load balancer can mark upstream targets as unhealthy automatically, but Vigilmon gives you external visibility and alerting on top of that.

Check upstream health via Admin API

curl http://localhost:8001/upstreams/my-upstream/health

# Returns each target with its health status:
{
  "data": [
    {
      "target": "backend-1.internal:3000",
      "health": "HEALTHY",
      "weight": 100
    },
    {
      "target": "backend-2.internal:3000",
      "health": "UNHEALTHY",
      "weight": 100
    }
  ]
}

Set up active health checks in Kong

Configure Kong to actively probe your upstreams so it stops routing to failed targets:

curl -X PATCH http://localhost:8001/upstreams/my-upstream \
  --data 'healthchecks.active.healthy.interval=10' \
  --data 'healthchecks.active.unhealthy.interval=5' \
  --data 'healthchecks.active.http_path=/health' \
  --data 'healthchecks.active.healthy.successes=2' \
  --data 'healthchecks.active.unhealthy.http_failures=3'

Expose upstream health for Vigilmon

Create an endpoint that aggregates upstream health and returns a simple 200/503:

// A lightweight sidecar service in Node.js
const express = require('express');
const axios = require('axios');

const app = express();
const KONG_ADMIN = process.env.KONG_ADMIN_URL || 'http://localhost:8001';
const UPSTREAM = process.env.KONG_UPSTREAM_NAME || 'my-upstream';

app.get('/upstream-health', async (req, res) => {
  try {
    const { data } = await axios.get(
      `${KONG_ADMIN}/upstreams/${UPSTREAM}/health`
    );

    const unhealthy = data.data.filter(t => t.health === 'UNHEALTHY');
    const allDown = unhealthy.length === data.data.length;

    if (allDown) {
      return res.status(503).json({
        status: 'down',
        unhealthy: unhealthy.map(t => t.target),
      });
    }

    res.json({
      status: 'ok',
      total: data.data.length,
      unhealthy: unhealthy.length,
    });
  } catch (err) {
    res.status(503).json({ status: 'error', message: err.message });
  }
});

app.listen(9090);

Monitor http://your-sidecar:9090/upstream-health with Vigilmon, keyword check "status":"ok".

Monitoring Individual Upstream Services

For each critical upstream behind Kong, add a direct Vigilmon monitor bypassing the gateway:

| Service | Direct URL | Kong Route | |---------|-----------|------------| | Auth service | http://auth.internal:3001/health | /api/auth | | User service | http://users.internal:3002/health | /api/users | | Payment service | http://payments.internal:3003/health | /api/payments |

This tells you whether a failure is in Kong itself or in a specific upstream. If Kong's monitor is green but the payments upstream is red, the gateway is healthy but routing to a broken backend.

Kong with Docker Compose

If you run Kong via Docker Compose, add a health check and a Vigilmon probe container:

# docker-compose.yml
services:
  kong:
    image: kong:3.6
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_ADMIN_LISTEN: "0.0.0.0:8001"
    ports:
      - "8000:8000"
      - "8001:8001"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 30s
      timeout: 10s
      retries: 3

  kong-db:
    image: postgres:16
    environment:
      POSTGRES_USER: kong
      POSTGRES_DB: kong
      POSTGRES_PASSWORD: kong

Expose the proxy port externally and point Vigilmon at https://api.example.com/health.

Alerting Configuration

In Vigilmon, set up alert escalation for your Kong monitors:

1. Open your monitor → Alert Channels
2. Immediate (0 min): Slack #infrastructure — gateway is potentially down
3. Escalation (5 min): PagerDuty or email to on-call — sustained outage
4. Recovery: Slack notification when Kong comes back up

For the upstream monitors, use a separate alert channel: #backend-health on Slack, with no PagerDuty escalation unless the upstream is critical.

Kubernetes Deployment

For Kong on Kubernetes (via Helm or Kong Ingress Controller), monitor via the service's external IP:

# Expose Kong's health via a Kubernetes service
apiVersion: v1
kind: Service
metadata:
  name: kong-health
spec:
  selector:
    app: kong
  ports:
    - port: 8001
      targetPort: 8001
  type: ClusterIP

Use an Ingress to expose /_kong/health externally:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kong-health-ingress
  annotations:
    konghq.com/strip-path: "true"
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /_kong/health
            pathType: Prefix
            backend:
              service:
                name: kong-health
                port:
                  number: 8001

Summary

| What to monitor | Endpoint | Vigilmon type | |-----------------|----------|---------------| | Kong gateway availability | https://api.example.com/health | HTTP GET, keyword "reachable":true | | Kong database connectivity | Admin API /status | HTTP GET (internal) | | Upstream health (all targets) | Sidecar aggregator /upstream-health | HTTP GET, keyword "status":"ok" | | Individual upstreams | Direct service health endpoints | HTTP GET per service |

With these monitors in place, you'll know within 60 seconds whether Kong itself is failing, whether its database is unreachable, or which specific upstream is causing errors — before users report a broken API.

Further Reading

• Monitoring Docker Containers with Vigilmon
• Kubernetes Pod Health Monitoring
• Monitoring GraphQL APIs with Vigilmon