How to Monitor Agones Game Server Infrastructure with Vigilmon

Agones is the open source, CNCF-hosted Kubernetes-native game server orchestration framework developed by Google. It solves a fundamental problem in multiplayer game infrastructure: standard Kubernetes Deployments are designed for stateless, interchangeable pods, but game servers are stateful, long-running processes each serving a fixed number of players for the duration of a session. Agones introduces custom resources — GameServer, Fleet, FleetAutoscaler, GameServerAllocation — that give your Kubernetes cluster first-class understanding of game server lifecycle.

Running Agones on GKE, EKS, AKS, or on-premises Kubernetes means that your matchmaking pipeline, fleet health, and player session availability all depend on the Agones controller and sidecar components staying healthy. When the controller crashes, game servers get stuck in intermediate states and players can't be allocated. When the fleet buffer runs dry, new players get denied. External monitoring catches these failures in seconds — before your support channel fills with player complaints.

This tutorial walks you through setting up comprehensive Agones monitoring with Vigilmon, covering controller health, fleet metrics, allocation success, and game server sidecar health.

Why Agones needs external monitoring

Kubernetes internal health probes (livenessProbe, readinessProbe) only tell you whether individual pods are running. They don't tell you whether the Agones control plane is functioning correctly or whether your fleet is actually ready to serve players:

Agones controller crash — GameServer objects get stuck in Starting state; Kubernetes reports pods as Running but no new game sessions can start
Fleet buffer exhaustion — all GameServers are in Allocated state; new allocation requests get rejected immediately, but kubectl get fleet shows everything as "ready"
Admission webhook timeout — the Agones ValidatingWebhookConfiguration fails; kubectl apply for GameServer manifests returns errors, but the controller pod is healthy
FleetAutoscaler sync failure — the autoscaler stops adjusting fleet size; capacity silently lags demand, leading to allocation failures during load spikes
agones-ping service down — clients can't measure regional latency to choose optimal game server regions, degrading matchmaking quality

In all of these cases, Kubernetes reports everything as healthy while players experience failures. External monitoring is the only reliable signal.

What you'll need

A running Kubernetes cluster with Agones installed (agones-system namespace present)
Agones controller and Agones ping service accessible from your monitoring network
A free Vigilmon account

Step 1: Expose the Agones controller health endpoint

The Agones controller exposes a health endpoint on port 8080. By default this is only accessible within the cluster. Expose it via a Kubernetes Service so Vigilmon can reach it:

# agones-controller-health-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: agones-controller-health
  namespace: agones-system
spec:
  type: LoadBalancer
  selector:
    app: agones-controller
  ports:
    - name: health
      port: 8080
      targetPort: 8080
      protocol: TCP

kubectl apply -f agones-controller-health-svc.yaml
kubectl get svc agones-controller-health -n agones-system
# NAME                        TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
# agones-controller-health    LoadBalancer   10.96.15.200   203.0.113.10     8080:31080/TCP   2m

Verify the health endpoint responds:

curl http://203.0.113.10:8080/healthz
# ok

Step 2: Monitor the Agones controller in Vigilmon

With the health endpoint exposed, add it to Vigilmon:

Log in to vigilmon.online and go to Monitors → New Monitor
Choose HTTP / HTTPS as the monitor type
Set the URL to http://203.0.113.10:8080/healthz
Set the check interval to 1 minute
Under Expected response, set:
- Status code: 200
- Response body contains: ok
Name the monitor Agones Controller Health
Save the monitor

Vigilmon will probe the health endpoint from multiple geographic regions. If the controller crashes or becomes unresponsive, Vigilmon confirms the failure via multi-region consensus and fires an alert within seconds — before any game server lifecycle operations fail silently.

Step 3: Monitor the agones-ping service

Agones ships an optional UDP/TCP ping service (agones-ping) that game clients use to measure round-trip latency to each cluster region, enabling client-side server selection. If this service goes down, clients can't measure latency and are forced to pick a server blind.

Expose the ping service health endpoint:

# agones-ping-health-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: agones-ping-health
  namespace: agones-system
spec:
  type: LoadBalancer
  selector:
    app: agones-ping
  ports:
    - name: health
      port: 8080
      targetPort: 8080
      protocol: TCP

kubectl apply -f agones-ping-health-svc.yaml
kubectl get svc agones-ping-health -n agones-system
# NAME                   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)          AGE
# agones-ping-health     LoadBalancer   10.96.15.201  203.0.113.11     8080:31081/TCP   1m

Add a second monitor in Vigilmon:

Monitors → New Monitor → HTTP / HTTPS
URL: http://203.0.113.11:8080/healthz
Name: Agones Ping Service Health
Interval: 1 minute
Expected status: 200

Step 4: Monitor fleet capacity with a custom metrics endpoint

For fleet-level metrics (GameServer state distribution, allocation rates), expose a lightweight metrics aggregator that queries the Kubernetes API and returns a JSON health payload. Create this as a small sidecar deployment in your cluster:

# agones-fleet-metrics-exporter.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: agones-fleet-metrics
  namespace: agones-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: agones-fleet-metrics
  template:
    metadata:
      labels:
        app: agones-fleet-metrics
    spec:
      serviceAccountName: agones-fleet-metrics-sa
      containers:
        - name: metrics
          image: bitnami/kubectl:latest
          command:
            - /bin/sh
            - -c
            - |
              while true; do
                READY=$(kubectl get gs --all-namespaces -o jsonpath='{.items[?(@.status.state=="Ready")].metadata.name}' | wc -w)
                ALLOCATED=$(kubectl get gs --all-namespaces -o jsonpath='{.items[?(@.status.state=="Allocated")].metadata.name}' | wc -w)
                UNHEALTHY=$(kubectl get gs --all-namespaces -o jsonpath='{.items[?(@.status.state=="Unhealthy")].metadata.name}' | wc -w)
                echo "{\"ready\":$READY,\"allocated\":$ALLOCATED,\"unhealthy\":$UNHEALTHY,\"status\":\"ok\"}" > /tmp/metrics.json
                sleep 30
              done &
              python3 -m http.server 9090 --directory /tmp
          ports:
            - containerPort: 9090
---
apiVersion: v1
kind: Service
metadata:
  name: agones-fleet-metrics
  namespace: agones-system
spec:
  type: LoadBalancer
  selector:
    app: agones-fleet-metrics
  ports:
    - port: 9090
      targetPort: 9090

Then add a Vigilmon monitor for this endpoint:

Monitors → New Monitor → HTTP / HTTPS
URL: http://<EXTERNAL-IP>:9090/metrics.json
Name: Agones Fleet Metrics
Interval: 1 minute
Expected status: 200
Response body contains: "status":"ok"

This confirms the fleet metrics exporter is running and returning a valid payload. For threshold-based alerting on unhealthy count, set Response body does not contain: "unhealthy":0 — or monitor it via your alerting rules below.

Step 5: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels → Add Channel → Email
Enter your on-call or ops team email
Assign the channel to all three Agones monitors

Webhook alerts (Slack, PagerDuty, Opsgenie)

Alert Channels → Add Channel → Webhook
Enter your Slack incoming webhook URL or PagerDuty Events API URL
Assign to all Agones monitors

When the Agones controller health check fails, Vigilmon sends a payload like:

{
  "monitor_name": "Agones Controller Health",
  "status": "down",
  "url": "http://203.0.113.10:8080/healthz",
  "started_at": "2024-06-01T14:05:00Z",
  "duration_seconds": 90
}

Use this to trigger automated remediation in your webhook handler:

# Check controller pod status when alert fires
kubectl get pods -n agones-system -l app=agones-controller
kubectl describe pod -n agones-system -l app=agones-controller | grep -A 10 Events

# Check GameServer states across all namespaces
kubectl get gameservers --all-namespaces

# Check fleet buffer
kubectl get fleet --all-namespaces

Key alert thresholds for Agones

| What to monitor | Alert condition | |---|---| | Agones controller health | Any non-200 response | | Agones ping service | Any non-200 response | | Fleet Ready count | Below fleet buffer minimum | | Fleet Unhealthy count | Greater than 0 for >5 minutes | | Controller pod restarts | >3 restarts in 15 minutes | | FleetAutoscaler sync | Any sync failure event | | Admission webhook latency | P95 >500ms | | Namespace resource quota | CPU/memory requests >85% |

Conclusion

Agones solves the hard problem of stateful game server lifecycle on Kubernetes. But the operational challenges shift to the control plane: controller health, fleet buffer availability, allocation success rates, and sidecar connectivity all need to be observed externally to catch failures before players do.

Vigilmon gives you multi-region consensus-based uptime monitoring with zero infrastructure overhead — no Prometheus, no Grafana, no alert manager configuration files. Add your Agones health endpoints, configure an alert channel, and you'll know about controller failures in seconds rather than minutes.