tutorial

Monitoring Kubevious with Vigilmon: UI Availability, Kubernetes Configuration Validation Health & Rule Engine Alerts

How to monitor Kubevious with Vigilmon — UI availability checks, Kubernetes configuration collector health, rule engine validation status, historical snapshot availability, and TLS certificate expiry alerts.

Kubevious is a Kubernetes configuration visualizer and validator — providing a graph-based view of cluster resources, historical snapshots of configuration changes, and a rule engine for enforcing custom policies across namespaces, deployments, and RBAC configurations. When the Kubevious UI goes down, platform teams lose the policy enforcement dashboard and configuration audit trail that compliance workflows depend on. When the Kubevious collector stops syncing cluster state, the UI shows stale data that silently misrepresents live cluster configuration — potentially masking misconfigurations the rule engine would otherwise catch. When the MySQL or SQLite backend becomes corrupted, historical snapshots are lost and compliance audits cannot reconstruct past cluster state. Vigilmon gives you external visibility into Kubevious UI availability, collector sync health, the rule engine's operational status, and the database backend that stores configuration history.

What You'll Build

  • HTTP monitor on the Kubevious UI to detect pod crashes and ingress failures
  • SSL certificate monitor for the Kubevious HTTPS endpoint
  • HTTP monitor on the Kubevious API server (backend data layer)
  • TCP monitor on the Kubevious service port for network-layer health checks
  • Alerting runbook mapping Kubevious failure modes to their root components

Prerequisites

  • A Kubernetes cluster with Kubevious installed (via Helm chart or manifest)
  • Kubevious exposed via Ingress or NodePort
  • A free account at vigilmon.online

Step 1: Understand Kubevious's Architecture and Health Surface

Kubevious consists of several interconnected components. Understanding their roles helps you place monitors at the right observation points:

# Check all Kubevious pods
kubectl get pods -n kubevious
# Expected running components:
# kubevious-* (UI frontend)
# kubevious-backend-* (REST API server)
# kubevious-collector-* (Kubernetes cluster state collector)
# kubevious-parser-* (configuration parser/validator)
# kubevious-mysql-* (MySQL database for history, if using bundled DB)

# Check Kubevious services
kubectl get svc -n kubevious

# Check Kubevious ingress
kubectl get ingress -n kubevious

The external failure signals to monitor are:

  1. The Kubevious UI HTTP/HTTPS endpoint (frontend reachability)
  2. The Kubevious backend REST API (drives all UI data)
  3. TLS certificate on the Kubevious ingress
  4. The MySQL/database backend (configuration history storage)

Step 2: Monitor the Kubevious UI

The frontend is the first line of visibility for Kubevious users. A 200 response with the Kubevious application confirms the UI pod is running and the ingress is routing correctly:

# Test the Kubevious UI
curl -I https://kubevious.example.com/
# Expected: HTTP/2 200 with Content-Type: text/html

# Check for the Kubevious application root
curl https://kubevious.example.com/ | grep -c 'kubevious\|id="root"'
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://kubevious.example.com/.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: kubevious (present in the HTML title or body).
  7. Label: Kubevious UI.
  8. Click Save.

This monitor detects frontend pod crashes, ingress controller failures, and DNS misconfigurations that prevent engineers from accessing the configuration visualization dashboard.

Step 3: Monitor the Kubevious Backend API

The Kubevious backend API server provides all data to the frontend — namespace trees, resource graphs, rule violations, and historical snapshots. When this service crashes, the UI loads but shows empty diagrams and no rule violations:

# Check the Kubevious backend service
kubectl get svc -n kubevious kubevious-backend

# Test the backend health endpoint (typically at /api/v1 or /healthz)
curl https://kubevious.example.com/api/v1/
# Expected: 200 or 404 with JSON response (not 502 or connection refused)

# Direct internal health check
kubectl exec -n kubevious deployment/kubevious-backend -- \
  wget -qO- http://localhost:4001/api/v1/config
  1. Add Monitor → HTTP.
  2. URL: https://kubevious.example.com/api/v1/ (or your backend API path).
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Label: Kubevious backend API.
  7. Click Save.

If the backend API path returns 404 by default (no root handler), use the collector status endpoint:

# Check collector last sync time via the API
curl https://kubevious.example.com/api/v1/top/summary
# Returns: JSON with lastestSnapshotId, collectorStatus, etc.
  1. Add Monitor → HTTP.
  2. URL: https://kubevious.example.com/api/v1/top/summary.
  3. Keyword: snapshotId (present when collector is syncing successfully).
  4. Label: Kubevious collector sync status.
  5. Click Save.

Step 4: Monitor the TLS Certificate

Kubevious serves sensitive Kubernetes configuration data — misconfigured resources, RBAC policies, and historical change logs. Its TLS certificate must remain valid to protect this data in transit and to avoid browser warnings that deter security-conscious users:

# Check the TLS secret for the Kubevious ingress
kubectl get ingress -n kubevious kubevious -o jsonpath='{.spec.tls[0].secretName}'
kubectl get secret <tls-secret-name> -n kubevious -o jsonpath='{.data.tls\.crt}' | \
  base64 -d | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: kubevious.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Step 5: Monitor the Kubevious Collector

The Kubevious collector continuously syncs cluster state from the Kubernetes API server and writes snapshots to the database. When the collector falls behind or stops syncing, the Kubevious rule engine continues to run against the last known snapshot — potentially missing new policy violations and RBAC misconfigurations that were introduced after the last sync:

# Check collector pod status
kubectl get pods -n kubevious -l app.kubernetes.io/component=collector
kubectl logs -n kubevious -l app.kubernetes.io/component=collector --tail=50
# Look for: "Snapshot saved" messages indicating active sync
# Look for: ERROR or connection refused to Kubernetes API server

# Check the last snapshot via the API
curl https://kubevious.example.com/api/v1/top/summary | jq '.latestSnapshot'
# Compare the snapshotDate with the current time — if > 5 minutes old, collector may be stuck

Create a Kubernetes CronJob to check collector freshness and alert on stale snapshots:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kubevious-collector-check
  namespace: kubevious
spec:
  schedule: "*/10 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: checker
              image: curlimages/curl:latest
              command:
                - /bin/sh
                - -c
                - |
                  SUMMARY=$(curl -sf http://kubevious-backend:4001/api/v1/top/summary)
                  if [ $? -ne 0 ]; then
                    echo "ALERT: Kubevious backend unreachable"
                    exit 1
                  fi
                  # Check if snapshotId is present (indicates recent sync)
                  echo "$SUMMARY" | grep -q "snapshotId" || {
                    echo "ALERT: No recent Kubevious snapshot — collector may be stuck"
                    exit 1
                  }
          restartPolicy: Never

Step 6: Monitor the MySQL Database Backend

Kubevious stores configuration history and rule violation snapshots in MySQL (or SQLite for small deployments). Database failures cause the Kubevious backend to lose the ability to write new snapshots and serve historical data:

# Check MySQL pod status (if using bundled MySQL)
kubectl get pods -n kubevious -l app.kubernetes.io/component=mysql

# Verify MySQL connectivity from the backend pod
kubectl exec -n kubevious deployment/kubevious-backend -- \
  mysql -h kubevious-mysql -u root -p$MYSQL_ROOT_PASSWORD -e "SELECT 1;"

# Check database disk usage (PVC)
kubectl get pvc -n kubevious
# Look for: pvc-kubevious-mysql — ensure capacity is not near 100%

Add a TCP monitor on the MySQL service port (if externally exposed) or monitor the backend API's ability to serve snapshot data:

  1. Add Monitor → HTTP.
  2. URL: https://kubevious.example.com/api/v1/history/timeframe.
  3. Expected status: 200.
  4. Keyword: snapshots (present in history response when database is healthy).
  5. Label: Kubevious history / database health.
  6. Click Save.

A failure on this monitor while the UI and backend API monitors remain healthy indicates the database backend has an issue storing or retrieving snapshots.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels and response runbooks:

| Monitor | Trigger | Immediate action | |---|---|---| | Kubevious UI HTTP | Non-200 or timeout | Check frontend pod: kubectl get pods -n kubevious -l app.kubernetes.io/component=ui; check ingress | | Kubevious backend API | Non-200 | Check backend pod: kubectl logs -n kubevious -l app.kubernetes.io/component=backend; restart if crash-looping | | Collector sync status | Keyword missing | Check collector pod logs; verify Kubernetes API server is reachable from the kubevious namespace | | TLS certificate | < 30 days | Renew cert-manager certificate: kubectl describe certificate -n kubevious; trigger manual renewal | | History/database health | Non-200 or keyword missing | Check MySQL pod and PVC disk usage; check backend logs for DB connection errors |

Alert grouping: Create a kubevious monitor group. When the backend crashes, the API, collector, and history monitors all fire simultaneously — the group view shows the backend as the single root cause rather than appearing as multiple independent failures.

Common Kubevious Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon signal | |---|---| | Kubevious UI pod OOMKilled | HTTP UI monitor fires with 502 | | Backend pod crash-loops | API monitor fires; UI loads but all diagrams show empty | | Collector loses connection to Kubernetes API | Collector sync monitor fires; snapshot data grows stale | | MySQL PVC disk full | History monitor fires with 500 error; new snapshots cannot be saved | | TLS certificate expires on ingress | SSL monitor fires at 30-day threshold; all HTTPS access fails | | Rule engine misses new violations | Collector stale → rule runs against old snapshot; collector monitor catches the staleness | | Backend OOM on large cluster (many resources) | API monitor shows response time spikes then timeout | | Database connection pool exhausted | History monitor returns 500; backend logs show "connection pool full" | | Ingress controller upgrade breaks routing | HTTP and API monitors fire; TCP monitor stays green | | Kubevious upgraded with DB migration failure | Backend fails to start; API monitor fires; check migration logs | | Namespace with 1000+ resources causes parser timeout | Parser pod crash-loops; API monitor shows intermittent failures |

Kubevious provides critical Kubernetes configuration visibility — catching RBAC misconfigurations, policy violations, and structural antipatterns that other tools miss. But when Kubevious itself goes dark, those violations go undetected. Vigilmon gives you external visibility into Kubevious UI availability, backend API health, collector sync freshness, database integrity, and TLS certificate validity. When a collector outage means new RBAC misconfigurations are silently skipped by the rule engine, Vigilmon catches the collector failure before compliance auditors catch the missed violations.

Start monitoring your Kubevious instance in under 5 minutes — register free at vigilmon.online.

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