tutorial

How to Monitor Apache APISIX with Vigilmon (HTTP, TCP, and Alerts)

Apache APISIX is the cloud-native API gateway built on top of nginx and etcd, widely used for traffic management, authentication, rate limiting, and service ...

Apache APISIX is the cloud-native API gateway built on top of nginx and etcd, widely used for traffic management, authentication, rate limiting, and service mesh. It handles millions of requests per second at companies like Tencent, NetEase, and Airwallex. When APISIX goes down — or a misconfigured plugin silently breaks routing — every API consumer behind it is affected simultaneously.

In this tutorial you'll set up end-to-end monitoring for an Apache APISIX deployment using Vigilmon — free tier, no credit card required.

Why APISIX needs external monitoring

APISIX is more than a proxy. It's a dynamic, plugin-powered gateway that can fail in ways that traditional infrastructure monitoring doesn't catch:

  • etcd connection loss — APISIX reads routes, upstreams, and plugins from etcd. If etcd becomes unavailable, APISIX can't load new configuration changes. Existing routes may still work (cached in memory), but new deployments silently fail and the admin API starts returning errors.
  • Plugin panic — a buggy Lua plugin can crash an APISIX worker. nginx restarts the worker, but the restart causes a short traffic interruption that doesn't appear in container health checks.
  • Upstream health probe misconfiguration — APISIX's built-in upstream health checks mark backends as unhealthy, but if you haven't configured external monitoring, you may not know that all traffic to a service is being rejected.
  • Admin API exposure — APISIX's admin API on port 9180 is often left internet-accessible by mistake. An external monitor can verify the admin port is not publicly reachable.
  • Data plane port loss — APISIX serves traffic on port 9080 (HTTP) and 9443 (HTTPS). Container restarts, port-binding failures, or TLS misconfiguration can take down the data plane while the control plane still reports healthy.

What you'll need

  • A running Apache APISIX deployment (Docker Compose or Kubernetes)
  • A free Vigilmon account — takes 30 seconds to create

Step 1: Identify APISIX health endpoints

APISIX exposes a built-in health endpoint on the control plane port:

Data plane health check:

GET http://<your-host>:9080/apisix/status

Returns {"status":{"connections":{"accepted":N,...},...}} when the data plane is serving. This endpoint does not require authentication and is available on the HTTP data plane port.

Admin API availability (should NOT be public):

GET http://<your-host>:9180/apisix/admin/routes

Returns the full route list. You should verify this is not reachable from outside your internal network.

Test the data plane endpoint from an external machine:

curl -f https://api.yourcompany.com/apisix/status
# Expected: {"status":{"connections":{...}}}

# Or via the HTTP port if exposed directly:
curl -f http://your-server:9080/apisix/status

If you have a custom upstream route for health checking, you can also create a dedicated health-check route in the APISIX admin API:

curl -X PUT http://localhost:9180/apisix/admin/routes/health-check \
  -H "X-API-KEY: your-admin-key" \
  -H "Content-Type: application/json" \
  -d '{
    "uri": "/healthz",
    "plugins": {
      "serverless-pre-function": {
        "phase": "rewrite",
        "functions": [
          "return function(conf, ctx)\n  ngx.status = 200\n  ngx.say(\"{\\\"status\\\":\\\"ok\\\"}\")\n  ngx.exit(200)\nend"
        ]
      }
    }
  }'

This creates a /healthz route that responds 200 directly from APISIX without hitting any upstream — useful for confirming the data plane is routing traffic without depending on upstream availability.

Step 2: Configure APISIX for external health probing

By default, the /apisix/status endpoint is accessible on port 9080. For production deployments, you typically put APISIX behind a load balancer. Make sure the health endpoint is reachable through your LB:

# In your apisix.yaml configuration
apisix:
  enable_control: true
  control:
    ip: "0.0.0.0"
    port: 9090

# The control API at :9090 exposes /v1/healthz
# which is separate from the data plane port

For Kubernetes, expose the health endpoints via a Service and configure readiness probes:

apiVersion: v1
kind: Service
metadata:
  name: apisix
spec:
  selector:
    app: apisix
  ports:
    - name: http
      port: 9080
      targetPort: 9080
    - name: https
      port: 9443
      targetPort: 9443
    - name: control
      port: 9090
      targetPort: 9090
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apisix
spec:
  template:
    spec:
      containers:
        - name: apisix
          readinessProbe:
            httpGet:
              path: /apisix/status
              port: 9080
            initialDelaySeconds: 10
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /apisix/status
              port: 9080
            initialDelaySeconds: 30
            periodSeconds: 30

Step 3: Set up HTTP monitoring in Vigilmon

Data plane health monitor:

  1. Log in to vigilmon.online and go to Monitors → New Monitor
  2. Choose HTTP / HTTPS as the type
  3. Set the URL to https://api.yourcompany.com/apisix/status
  4. Set the check interval to 1 minute
  5. Under Expected response, set:
    • Status code: 200
  6. Save the monitor

Custom health route monitor:

If you created the /healthz route in Step 1, create a second HTTP monitor for https://api.yourcompany.com/healthz with expected body "status":"ok". This confirms that the APISIX routing engine is actually processing requests end-to-end, not just that the nginx process is alive.

Admin API exposure check (important):

Create an HTTP monitor pointing to https://your-public-ip:9180/apisix/admin/routes. Under Expected response, set the expected status code to 403 or connection refused. If Vigilmon gets a 200 back from this monitor, your admin API is publicly exposed and you need to firewall it immediately.

Step 4: Monitor APISIX ports via TCP

APISIX data plane ports must be reachable for your APIs to function:

  1. In Vigilmon, go to Monitors → New Monitor
  2. Choose TCP Port
  3. Enter your APISIX host and port 9080 (HTTP data plane)
  4. Save the monitor

Repeat for port 9443 (HTTPS data plane). These TCP monitors catch the case where APISIX's nginx worker crashes and the port stops accepting connections — which can happen faster than an HTTP-level health check would fire.

| Monitor | Type | What it catches | |---------|------|-----------------| | /apisix/status | HTTP | nginx worker up, routing functional | | /healthz custom route | HTTP | Full request processing pipeline | | Port 9080 | TCP | HTTP data plane port binding | | Port 9443 | TCP | HTTPS data plane port binding | | etcd port 2379 | TCP | etcd availability for config sync |

Step 5: Monitor etcd availability

APISIX stores all its configuration — routes, upstreams, plugins, consumers — in etcd. If etcd loses quorum, APISIX can no longer reload configuration. Live traffic continues (APISIX caches config in memory), but any route changes, upstream updates, or plugin modifications will silently fail to apply.

Add a TCP monitor for your etcd cluster:

  1. In Vigilmon, create a TCP Port monitor for your etcd host on port 2379
  2. If you have a 3-node etcd cluster, add a monitor for each node

You can also configure etcd to expose a health endpoint and create an HTTP monitor for it:

curl http://etcd-host:2379/health
# Returns: {"health":"true"}

Step 6: Configure webhook alerts

APISIX is your API gateway — when it goes down, every service it proxies becomes unreachable. Alert routing should reflect the blast radius:

  1. In Vigilmon, go to Alert Channels → Add Channel → Webhook
  2. Enter your PagerDuty webhook URL for immediate on-call escalation
  3. Assign the channel to the data plane HTTP and TCP monitors

For etcd and admin API monitors, you may want a separate Slack channel rather than immediate pager alerts — these are important but less urgent than the data plane being down.

Example Vigilmon incident payload for APISIX:

{
  "monitor_name": "APISIX data plane /apisix/status",
  "status": "down",
  "url": "https://api.yourcompany.com/apisix/status",
  "started_at": "2026-03-10T14:22:00Z",
  "duration_seconds": 47
}

Step 7: Create a status page for API consumers

If your APISIX gateway serves external developers or partner APIs, a status page lets them self-diagnose outages without filing support tickets:

  1. In Vigilmon, go to Status Pages → New Status Page
  2. Name it "API Gateway Status" or your product's API status page name
  3. Add your APISIX HTTP monitors (data plane health, custom /healthz)
  4. Optionally group monitors by the service they represent
  5. Publish and share the URL in your API documentation and developer portal

Step 8: Monitor APISIX dashboard (APISIX Dashboard / Admin UI)

If you use APISIX Dashboard for route management, add an HTTP monitor for it:

  1. Create an HTTP monitor pointing to https://apisix-dashboard.yourcompany.com
  2. Set expected status to 200
  3. Assign it to your platform team's Slack alert channel

The dashboard going down doesn't affect live traffic, but it blocks engineers from making routing changes — worth knowing about quickly.

Putting it all together

Complete monitoring setup for Apache APISIX:

APISIX /apisix/status         → HTTP monitor, 1-min interval, status: 200
APISIX /healthz custom route  → HTTP monitor, 1-min interval, body: "status":"ok"
APISIX HTTP data plane        → TCP monitor on port 9080
APISIX HTTPS data plane       → TCP monitor on port 9443
etcd node 1                   → TCP monitor on port 2379
etcd node 2                   → TCP monitor on port 2379
etcd node 3                   → TCP monitor on port 2379
APISIX admin API (exposure)   → HTTP monitor, expected 403/timeout
APISIX Dashboard              → HTTP monitor, 1-min interval, status: 200

Alert channel: PagerDuty for data plane monitors, Slack for etcd/dashboard Status page: published to your developer portal

What's next

  • SSL certificate monitoring — APISIX handles TLS termination for all your APIs. If the TLS certificate expires, every HTTPS consumer gets a hard failure. Vigilmon monitors cert expiry and alerts you before it happens.
  • Upstream health correlation — if your APISIX upstream health checks are marking backends unhealthy, the root cause is usually on the backend side. Vigilmon lets you monitor both the gateway and the upstream services independently, so you can quickly tell whether an incident is APISIX or the upstream.
  • Latency baseline — APISIX should add less than 1ms of latency to most requests. Vigilmon response time charts help you detect plugin-introduced latency regressions after configuration changes.

Get started free at vigilmon.online — no credit card required, and your first monitors are running in under a minute.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles