How to Monitor Your Kubernetes Cluster with Vigilmon

Kubernetes adds resilience through automatic restarts and rescheduling — but it also adds complexity. Pods crash and restart silently. Services become unreachable due to failed readiness probes. Ingresses misconfigure and start routing traffic to dead pods. Your app can be "running" in Kubernetes while users see nothing but errors.

This guide covers how to use Vigilmon to monitor the externally-visible health of your Kubernetes-hosted services — the part that matters most to your users.

What Vigilmon Monitors in a Kubernetes Stack

Vigilmon focuses on external, user-facing health — not cluster internals. That means:

• Ingress/LoadBalancer endpoints: Is your app actually reachable from the internet?
• Health check endpoints: Are your pods healthy, or just running?
• Service-specific endpoints: Is your database sidecar, Redis, or queue healthy?

For cluster internals (node CPU, pod restarts, etcd health), you'd use Prometheus + Grafana or Datadog. Vigilmon is your external eyes — what users experience.

Kubernetes Health Check Best Practices

Before monitoring with Vigilmon, make sure your Kubernetes services expose proper health endpoints.

Liveness and Readiness Probes

Define these in your Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api
        image: your-app:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 30
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 2

Implement the Health Endpoints

Liveness (/health/live): Is the process alive and not deadlocked?
Readiness (/health/ready): Can this pod serve traffic right now?

// Express.js example

// Liveness - just check process is alive
app.get('/health/live', (req, res) => {
  res.json({ status: 'ok' });
});

// Readiness - check dependencies
app.get('/health/ready', async (req, res) => {
  try {
    // Check DB connection
    await db.raw('SELECT 1');
    // Check Redis connection
    await redis.ping();
    res.json({ status: 'ready', db: 'ok', redis: 'ok' });
  } catch (err) {
    res.status(503).json({ status: 'not_ready', error: err.message });
  }
});

Setting Up Vigilmon for Kubernetes Services

Once your services are exposed via an Ingress or LoadBalancer:

1. Sign up at vigilmon.online
2. Add HTTP Monitor → https://api.yourdomain.com/health/ready
3. Check interval: 1 minute
4. Expected status: 200
5. Alert on first failure (Kubernetes should be self-healing; if Vigilmon sees a failure, something is seriously wrong)

Monitor Multiple Services

For a typical Kubernetes setup, create monitors for:

https://api.yourdomain.com/health/ready     → API service
https://yourdomain.com/                     → Frontend (check for 200)
https://api.yourdomain.com/health/db        → Database connectivity
https://api.yourdomain.com/health/worker    → Background worker status

Kubernetes-Specific Failure Modes to Watch

ImagePullBackOff / CrashLoopBackOff

Your pod keeps restarting. Kubernetes won't route traffic to unhealthy pods, so your service becomes unavailable. Vigilmon will catch this as an HTTP timeout or 503.

Ingress Misconfiguration

A bad Ingress rule or missing TLS secret causes your domain to stop resolving. Vigilmon's external HTTP check catches this immediately — your internal Kubernetes monitoring won't.

Resource Limits Causing OOMKills

resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"  # Hitting this causes OOMKill
    cpu: "500m"

When a pod gets OOMKilled, Kubernetes restarts it. During the restart window (which can be 30-60+ seconds with backoff), your service is partially down. Vigilmon catches this as intermittent failures.

Service Selector Mismatch

A common bug after refactoring: your Service selector stops matching your pod labels. Traffic gets silently dropped.

# Service
spec:
  selector:
    app: api-server  # Must match pod labels exactly

Vigilmon catches this as 503/timeout errors from your Ingress.

Multi-Environment Monitoring

For Kubernetes setups with multiple environments:

# Production
https://api.prod.yourdomain.com/health/ready

# Staging
https://api.staging.yourdomain.com/health/ready

# Development
https://api.dev.yourdomain.com/health/ready

In Vigilmon, group these with labels or naming conventions. Set stricter alerting for production (immediate page on first failure) and softer alerting for staging (warn only).

SSL Certificate Monitoring

Kubernetes TLS certificates (from cert-manager or cloud providers) have expiration dates. Vigilmon monitors SSL expiry and alerts you 30 days before expiration — before Let's Encrypt fails to renew and your site goes HTTPS-dead.

Alerting Configuration for Kubernetes

{
  "monitor": "k8s-api-health",
  "alert_on": {
    "status": "down",
    "response_time_ms": 2000,
    "ssl_days_remaining": 30
  },
  "channels": {
    "critical": ["pagerduty", "slack-ops"],
    "warning": ["slack-alerts"]
  }
}

Monitoring Checklist for Kubernetes

• [ ] Liveness and readiness probes defined in Deployments
• [ ] External health endpoints accessible via Ingress
• [ ] Vigilmon HTTP monitors for each exposed service
• [ ] SSL certificate expiry monitoring enabled
• [ ] Maintenance windows configured for rolling deployments
• [ ] Separate monitor groups for prod vs staging

Start monitoring your Kubernetes services for free →

---

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.