Uptime monitoring for Gloo Edge

Gloo Edge is a Kubernetes-native API gateway and ingress controller built on Envoy Proxy, developed by Solo.io. It handles north-south traffic into your Kubernetes cluster — routing external requests to backend services, enforcing authentication, rate limiting, and applying traffic policies. When the Gloo Edge control plane goes down or the Envoy data plane loses its configuration, all inbound API traffic stops routing correctly. External monitoring is the only reliable way to detect this from the perspective your users actually experience.

This tutorial covers production-grade uptime monitoring for Gloo Edge using Vigilmon. We will walk through:

• Monitoring the Gloo Edge control plane health endpoint
• Admin API monitoring on port 9091
• Envoy admin interface availability
• SSL certificate alerts for gateway endpoints
• Heartbeat monitoring for scheduled traffic policy updates

Prerequisites

• Gloo Edge 1.15+ installed in a Kubernetes cluster
• kubectl access to the gloo-system namespace
• A service exposed through Gloo Edge with a public endpoint
• A free account at vigilmon.online

Part 1: Verify Gloo Edge component health

Before adding monitors, confirm the Gloo Edge pods are running and the health endpoints are responding.

# Check all Gloo Edge pods
kubectl get pods -n gloo-system

# Expected output includes gloo, gateway, gateway-proxy, discovery pods
# NAME                              READY   STATUS    RESTARTS   AGE
# discovery-7d4b9ff768-xk8p2       1/1     Running   0          5d
# gateway-5f9b8c7d4d-jvzkq         1/1     Running   0          5d
# gateway-proxy-6d7f8c9b4c-mnpqr   1/1     Running   0          5d
# gloo-84b9d6c5f4-rtwlx            1/1     Running   0          5d

Confirm the control plane health endpoint is reachable:

# Port-forward the gloo control plane health port
kubectl port-forward -n gloo-system deploy/gloo 9091:9091 &

curl http://localhost:9091/health
# Expected: HTTP 200 with body "OK"

Check the gateway proxy (Envoy) admin interface:

kubectl port-forward -n gloo-system deploy/gateway-proxy 19000:19000 &

curl http://localhost:19000/ready
# Expected: "LIVE"

Part 2: Monitor the Gloo Edge control plane health endpoint

The Gloo Edge control plane exposes a /health endpoint on port 9091 of the gloo deployment. This is the primary signal that the xDS control plane — which programs Envoy with routing rules — is operational.

To expose this endpoint externally for Vigilmon to reach:

Option A — NodePort service (for non-production or management monitoring):

# gloo-health-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: gloo-health-external
  namespace: gloo-system
spec:
  type: NodePort
  selector:
    gloo: gloo
  ports:
    - name: health
      port: 9091
      targetPort: 9091
      nodePort: 30991

Apply it:

kubectl apply -f gloo-health-nodeport.yaml

Verify from external:

curl http://your-node-ip:30991/health
# Expected: "OK"

Option B — Expose via the gateway proxy itself. Create a Gloo VirtualService that routes an internal /gloo-health path to the control plane health port. This avoids NodePort exposure.

Add the Vigilmon monitor:

1. Log in to vigilmon.online and click Add Monitor.
2. Choose HTTP(S) monitor.
3. Enter: http://your-node-ip:30991/health (or your external URL).
4. Set interval to 1 minute.
5. Set expected status code to 200.
6. Add a keyword check: must contain OK.
7. Add your alert channel.
8. Click Save.

Part 3: Monitor the Gloo Edge admin API (port 9091)

The Gloo control plane's admin API on port 9091 provides metrics, configuration dump, and readiness signals. Monitoring this API independently from the gateway proxy data plane helps you distinguish between control plane failures (routing config stuck) and data plane failures (Envoy not forwarding traffic).

# Get config snapshot via admin API
curl http://your-node-ip:30991/snapshots/proxies | jq '.[] | .name'

Add the TCP monitor to confirm the admin port is reachable:

1. Click Add Monitor → TCP monitor.
2. Enter your node hostname and port 30991 (or the NodePort you configured).
3. Set interval to 1 minute.
4. Add your alert channel.
5. Click Save.

This catches cases where the Gloo pod itself crashes or the port binding drops — before you notice it in routing failures.

Part 4: Monitor the Envoy admin interface

The Envoy proxy (gateway-proxy) exposes its own admin interface on port 19000. This interface reports Envoy's internal state — listener status, cluster health, routing rules as they were last received from the Gloo control plane.

Expose the Envoy admin port:

# envoy-admin-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: gateway-proxy-admin-external
  namespace: gloo-system
spec:
  type: NodePort
  selector:
    gateway-proxy: live
  ports:
    - name: admin
      port: 19000
      targetPort: 19000
      nodePort: 31900

kubectl apply -f envoy-admin-nodeport.yaml
curl http://your-node-ip:31900/ready
# Expected: "LIVE"

Add the Vigilmon monitor:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: http://your-node-ip:31900/ready
3. Set interval to 1 minute.
4. Set expected status code to 200.
5. Add a keyword check: must contain LIVE.
6. Add your alert channel.
7. Click Save.

The /ready endpoint is Envoy's canonical readiness signal — it returns LIVE only when Envoy has received an initial xDS configuration from the control plane and is ready to forward traffic.

Part 5: Monitor your gateway-proxied services

The most important check is whether actual API traffic routes correctly through Gloo Edge. Add monitors for the services exposed behind your gateway:

# List all VirtualServices and their exposed routes
kubectl get virtualservice -A

# Get the external IP of the gateway proxy LoadBalancer
kubectl get svc -n gloo-system gateway-proxy
# NAME            TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
# gateway-proxy   LoadBalancer   10.96.110.5     203.0.113.20    80:32080/TCP,443:32443/TCP

Add HTTP monitors for each externally routed service:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: https://api.yourdomain.com/health (one of your upstream services routed through Gloo Edge).
3. Set interval to 1 minute.
4. Set expected status code to 200.
5. Add your alert channel.
6. Click Save.

This end-to-end check catches failures anywhere in the Gloo Edge data path: the gateway-proxy pod, xDS configuration sync, upstream service routing, or the upstream service itself.

Part 6: Heartbeat monitoring for scheduled traffic policy updates

Gloo Edge traffic policies — rate limits, authentication, routing rules — are often updated through automated GitOps pipelines. A pipeline that exits cleanly but fails to apply a policy is a silent misconfiguration. Vigilmon heartbeats detect it.

Add heartbeat to your policy update pipeline

For a shell-based GitOps sync:

#!/usr/bin/env bash
# /usr/local/bin/gloo-policy-sync.sh

set -euo pipefail

POLICY_DIR="/opt/gloo-policies"
HEARTBEAT_URL="https://vigilmon.online/api/heartbeat/YOUR_TOKEN"

echo "[$(date)] Syncing Gloo Edge traffic policies..."

# Apply all VirtualService and RouteTable manifests
kubectl apply -f "$POLICY_DIR/virtual-services/"
kubectl apply -f "$POLICY_DIR/route-tables/"
kubectl apply -f "$POLICY_DIR/auth-configs/"

# Wait for gateway-proxy to reload (Gloo xDS is usually < 5s)
sleep 10

# Validate the proxy accepted the new config
PROXY_STATUS=$(glooctl check 2>&1 | grep -i "no problems detected" || true)
if [ -z "$PROXY_STATUS" ]; then
  echo "[$(date)] WARNING: glooctl check detected issues" >&2
  glooctl check >&2
  exit 1
fi

echo "[$(date)] Policy sync successful"
curl -fsS --retry 3 "$HEARTBEAT_URL" > /dev/null
echo "[$(date)] Heartbeat sent"

For a Kubernetes CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: gloo-policy-sync
  namespace: gloo-system
spec:
  schedule: "0 */4 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: gloo-policy-sync-sa
          containers:
            - name: sync
              image: bitnami/kubectl:latest
              command:
                - /bin/bash
                - /scripts/gloo-policy-sync.sh
              env:
                - name: HEARTBEAT_URL
                  valueFrom:
                    secretKeyRef:
                      name: vigilmon-secrets
                      key: heartbeat-url
          restartPolicy: OnFailure

Create the heartbeat monitor in Vigilmon

1. In Vigilmon, click Add Monitor → Heartbeat monitor.
2. Name it: Gloo Edge policy sync.
3. Set expected interval to 4 hours (matching your sync schedule).
4. Set grace period to 30 minutes.
5. Copy the heartbeat URL and configure it in your script or Kubernetes secret.
6. Click Save.

If the policy sync job fails or is skipped, Vigilmon alerts you before your traffic policies drift from the desired state.

Part 7: SSL certificate monitoring

Gloo Edge typically terminates TLS at the gateway proxy using certificates stored in Kubernetes Secrets. If a certificate expires, HTTPS traffic to all services behind the gateway fails — even if the upstream services are healthy.

1. In Vigilmon, click Add Monitor → SSL monitor.
2. Enter your gateway hostname: api.yourdomain.com.
3. Set alert threshold to 14 days before expiry.
4. Add your alert channel.
5. Click Save.

Check the certificate stored in Kubernetes:

# List TLS secrets used by Gloo Edge
kubectl get secrets -n gloo-system --field-selector type=kubernetes.io/tls

# Check expiry of a specific cert
kubectl get secret your-tls-secret -n gloo-system \
  -o jsonpath='{.data.tls\.crt}' | base64 -d \
  | openssl x509 -noout -dates

To use cert-manager with Gloo Edge for automated renewal:

# certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gloo-gateway-tls
  namespace: gloo-system
spec:
  secretName: gloo-gateway-tls-secret
  dnsNames:
    - api.yourdomain.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

Vigilmon's 14-day alert catches cert-manager renewal failures before they take down your gateway.

Summary

Your Gloo Edge deployment now has six layers of external monitoring:

1. Control plane health check — polls /health on port 9091 to confirm the xDS control plane is operational.
2. Admin API TCP check — verifies the admin port is bound and accepting connections.
3. Envoy admin readiness check — confirms the gateway-proxy has received and applied its xDS configuration.
4. End-to-end service check — monitors actual API traffic routed through the gateway to verify the full data path.
5. Heartbeat monitor — your traffic policy sync pipeline pings Vigilmon; missing pings mean policy updates were skipped.
6. SSL certificate monitor — alerts you 14 days before any gateway TLS certificate expires.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any failure in your Gloo Edge API gateway stack.

Monitor your Gloo Edge infrastructure free at vigilmon.online

#gloo #envoy #kubernetes #apigateway #monitoring #devops