Monitoring Sealos with Vigilmon

Sealos is an open-source cloud operating system that turns a bare Kubernetes cluster into a consumer-grade private cloud platform: web-based desktop, per-tenant resource isolation, an app store, serverless functions, MinIO object storage, and managed databases — all on infrastructure you control. It's the self-hosted alternative to AWS or GCP for teams that want cloud-platform productivity without public cloud dependency. But that richness means many critical components: the cloud controller manager, the desktop frontend, MinIO, database operators, ingress, cert-manager, and per-tenant namespace health all need to be watched. Vigilmon gives you a single pane of glass across every layer of the Sealos stack.

What You'll Set Up

• Sealos cloud controller manager health monitor
• Kubernetes API server availability check
• Sealos desktop UI uptime monitor (the web-based cloud desktop)
• Per-tenant namespace resource quota alerting
• MinIO object storage health check
• Database operator pod health monitors (PostgreSQL, MySQL)
• Ingress controller health monitor
• Cert-Manager health and certificate expiry alerts
• Cluster-wide resource utilization alerting (>85% CPU/memory)
• Internal OCI registry health check

Prerequisites

• A running Sealos installation (self-hosted on a Kubernetes cluster)
• kubectl access to the cluster
• Sealos desktop accessible over HTTPS
• A free Vigilmon account

Why Monitoring Sealos Is Multi-Layered

Sealos sits on top of Kubernetes, not beside it. A failure at any layer cascades upward:

• Kubernetes control plane failure → Sealos controller cannot reconcile tenants → all tenant operations fail
• Sealos controller failure → Tenant lifecycle management breaks → users can't create/delete workloads
• MinIO failure → Object storage unavailable → any app using cloud storage breaks
• Ingress failure → All tenant HTTP traffic drops → every deployed application becomes unreachable
• Cert-Manager failure → TLS certificates stop renewing → HTTPS errors across all tenant apps

Each layer needs its own monitor, and alert escalation should reflect the blast radius.

Step 1: Monitor the Kubernetes API Server

Sealos cannot function without a healthy Kubernetes API server. This is the foundation check.

Add a Vigilmon HTTP monitor for the Kubernetes API health endpoint:

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your Kubernetes API health URL: https://<k8s-api-server>:6443/healthz
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Alert thresholds, set Failure threshold to 1 (any failure should alert immediately).
7. Click Save.

If your cluster's API server is behind a load balancer, use the load balancer endpoint. For internal clusters, use a monitoring host inside the cluster network.

Alert rule: critical immediately — Kubernetes API server unavailability makes all Sealos operations impossible.

Step 2: Monitor the Sealos Cloud Controller Manager

The sealos-cloud-controller-manager is the Sealos-specific Kubernetes operator that manages tenant lifecycle: namespace creation, resource quota enforcement, billing, and user management. If it crashes, no new tenants can be created and existing tenant configurations cannot be updated.

Check controller health:

# Check the controller deployment
kubectl get deployment sealos-cloud-controller-manager \
  -n sealos-system -o jsonpath='{.status.availableReplicas}'

# View recent logs for errors
kubectl logs -n sealos-system \
  -l app=sealos-cloud-controller-manager --tail=50

Expose a health check endpoint via a simple HTTP probe:

# Add this to a monitoring script that Vigilmon calls
kubectl get deployment sealos-cloud-controller-manager \
  -n sealos-system -o jsonpath='{.status.availableReplicas}' | grep -q "^[1-9]" \
  && curl -s "$VIGILMON_CONTROLLER_HEARTBEAT_URL"

Or use a Kubernetes-native approach with a ClusterIP service and a readiness probe:

# Check the controller pod's readiness
kubectl get pods -n sealos-system \
  -l app=sealos-cloud-controller-manager \
  -o jsonpath='{.items[0].status.containerStatuses[0].ready}'

Add a Vigilmon Heartbeat monitor named sealos-controller-health with a 2-minute expected interval.

Alert rule: critical if the controller has 0 available replicas — tenant lifecycle operations are completely blocked.

Step 3: Monitor the Sealos Desktop UI

The Sealos desktop is the web interface users interact with. If the frontend is down, users cannot access their cloud desktop, deploy applications, or manage their resources.

Add a Vigilmon HTTP monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter your Sealos desktop URL: https://cloud.yourdomain.com (or your self-hosted Sealos domain).
3. Set Check interval to 1 minute.
4. Set Expected HTTP status to 200.
5. Under Keyword matching, add Sealos or any string that appears on the desktop login page to confirm real content is served.
6. Click Save.

Also monitor the Sealos API backend directly:

1. Add another HTTP monitor for the API endpoint: https://cloud.yourdomain.com/api/auth/session
2. Set Expected HTTP status to 200 or 401 (unauthenticated is still a healthy API response).

Alert rule: critical if the desktop UI returns non-200 or keyword not found — users have lost access to their entire cloud environment.

Step 4: Monitor Per-Tenant Namespace Resource Quotas

In Sealos, each tenant gets a Kubernetes namespace with resource quotas. When a tenant hits their quota, their pods can't be scheduled and their workloads fail silently. Monitor quota usage across all tenant namespaces:

# List all tenant namespaces with quota usage
kubectl get resourcequota -A \
  -o custom-columns="NAMESPACE:.metadata.namespace,\
CPU_USED:.status.used.cpu,CPU_LIMIT:.status.hard.cpu,\
MEM_USED:.status.used.memory,MEM_LIMIT:.status.hard.memory"

Set up a monitoring script that counts namespaces near quota limits:

#!/usr/bin/env python3
import subprocess, json, os, requests

result = subprocess.run(
    ["kubectl", "get", "resourcequota", "-A", "-o", "json"],
    capture_output=True, text=True
)
quotas = json.loads(result.stdout)["items"]

near_limit = []
for q in quotas:
    used = q["status"].get("used", {})
    hard = q["status"].get("hard", {})
    ns = q["metadata"]["namespace"]
    
    # Check CPU quota usage
    cpu_used = float(used.get("cpu", "0").rstrip("m")) / 1000
    cpu_limit = float(hard.get("cpu", "999").rstrip("m")) / 1000
    if cpu_limit > 0 and cpu_used / cpu_limit > 0.85:
        near_limit.append(f"{ns}: CPU {cpu_used/cpu_limit*100:.0f}%")

if not near_limit:
    requests.get(os.environ["VIGILMON_QUOTA_HEARTBEAT_URL"])
else:
    print(f"Namespaces near quota: {near_limit}")

Alert rule: warning if any tenant namespace is above 85% of its resource quota; critical if a namespace is at 100% (pods will fail to schedule).

Step 5: Monitor MinIO Object Storage

Sealos uses MinIO for object storage. MinIO failure breaks any Sealos feature that stores files, container images, backups, or user uploads.

Check MinIO health:

# MinIO health endpoint
curl -s http://minio.sealos-system.svc.cluster.local:9000/minio/health/live

# MinIO readiness endpoint
curl -s http://minio.sealos-system.svc.cluster.local:9000/minio/health/ready

Add a Vigilmon HTTP monitor for MinIO:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter your MinIO health URL (internal or load-balanced): http://<minio-endpoint>:9000/minio/health/live
3. Set Check interval to 1 minute.
4. Set Expected HTTP status to 200.
5. Click Save.

Also monitor MinIO storage capacity:

# Check total MinIO storage usage via mc (MinIO client)
mc admin info minio --json | python3 -c "
import sys, json
info = json.load(sys.stdin)
for server in info.get('servers', []):
    for disk in server.get('drives', []):
        used_pct = disk['usedSpace'] / disk['totalSpace'] * 100
        if used_pct > 80:
            print(f'DISK_FULL: {disk[\"endpoint\"]} {used_pct:.1f}%')
            exit(1)
"
[ $? -eq 0 ] && curl -s "$VIGILMON_MINIO_CAPACITY_HEARTBEAT_URL"

Alert rules:

• critical if MinIO health endpoint returns non-200
• warning at MinIO storage >80% capacity
• critical at MinIO storage >90% capacity

Step 6: Monitor Database Operator Health

Sealos provides managed databases via Kubernetes operators (typically CloudNativePG for PostgreSQL and similar for MySQL). If the operator crashes, users cannot provision new databases and existing database operations may fail.

Check operator pod health:

# Check CloudNativePG operator
kubectl get deployment -n cnpg-system cnpg-controller-manager \
  -o jsonpath='{.status.availableReplicas}'

# Check for database cluster errors
kubectl get clusters.postgresql.cnpg.io -A \
  -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase"

Add Vigilmon heartbeat monitors for each database operator:

#!/bin/bash
# PostgreSQL operator health check

PG_REPLICAS=$(kubectl get deployment -n cnpg-system \
  cnpg-controller-manager \
  -o jsonpath='{.status.availableReplicas}' 2>/dev/null || echo "0")

if [ "$PG_REPLICAS" -gt 0 ]; then
  curl -s "$VIGILMON_PG_OPERATOR_HEARTBEAT_URL"
fi

Alert rule: critical if the database operator has 0 available replicas — database provisioning for all tenants is blocked.

Step 7: Monitor Ingress Controller Health

The ingress controller routes HTTP traffic to all tenant applications. An ingress crash drops all tenant application traffic simultaneously.

Check ingress controller health:

# Check nginx ingress controller (or whichever ingress Sealos uses)
kubectl get deployment -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.availableReplicas}'

Add a Vigilmon HTTP monitor that hits the ingress controller's own status endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the ingress controller metrics endpoint: http://<ingress-controller-ip>:10254/healthz
3. Set Check interval to 1 minute.
4. Set Expected HTTP status to 200.

Or use a real tenant application URL as a proxy health check:

1. Pick a stable, low-traffic tenant application URL.
2. Add it as an HTTP monitor with the expected response.
3. If this URL goes down, the ingress controller or that specific app is down.

Alert rule: critical immediately — ingress failure drops all tenant application traffic.

Step 8: Monitor Cert-Manager and Certificate Expiry

Cert-Manager automates TLS certificate issuance and renewal for all tenant applications. A cert-manager failure means certificates stop renewing and HTTPS errors will cascade across all tenant apps.

Check cert-manager health:

# Check cert-manager deployment
kubectl get deployment -n cert-manager cert-manager \
  -o jsonpath='{.status.availableReplicas}'

# Check for certificates expiring soon (<14 days)
kubectl get certificates -A \
  -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,\
READY:.status.conditions[0].status,EXPIRY:.status.notAfter" \
  | grep -v "True"

Add a Vigilmon SSL certificate monitor for your Sealos domain:

1. Click Add Monitor → SSL Certificate.
2. Enter your Sealos domain: cloud.yourdomain.com
3. Set Alert threshold to 14 days before expiry.
4. Set Check interval to 1 day.
5. Click Save.

Add a heartbeat for the cert-manager controller itself:

#!/bin/bash
CM_REPLICAS=$(kubectl get deployment -n cert-manager cert-manager \
  -o jsonpath='{.status.availableReplicas}' 2>/dev/null || echo "0")

if [ "$CM_REPLICAS" -gt 0 ]; then
  curl -s "$VIGILMON_CERTMANAGER_HEARTBEAT_URL"
fi

Alert rules:

• critical if cert-manager controller is down
• warning if any certificate expires within 14 days
• critical if any certificate expires within 3 days

Step 9: Monitor Cluster-Wide Resource Utilization

Monitor aggregate resource usage across all tenant namespaces to prevent scheduling failures:

# Aggregate CPU/memory usage across cluster
kubectl top nodes --no-headers | awk '
{
  gsub(/%/, "", $3); cpu_total += $3;
  gsub(/%/, "", $5); mem_total += $5;
  count++
}
END {
  print "avg_cpu=" cpu_total/count
  print "avg_mem=" mem_total/count
}'

Set up a Vigilmon heartbeat that alerts when cluster utilization approaches limits:

#!/bin/bash
AVG_CPU=$(kubectl top nodes --no-headers | \
  awk '{gsub(/%/,"",$3); sum+=$3; n++} END {print sum/n}')
AVG_MEM=$(kubectl top nodes --no-headers | \
  awk '{gsub(/%/,"",$5); sum+=$5; n++} END {print sum/n}')

if (( $(echo "$AVG_CPU < 85" | bc -l) )) && \
   (( $(echo "$AVG_MEM < 85" | bc -l) )); then
  curl -s "$VIGILMON_CLUSTER_RESOURCE_HEARTBEAT_URL"
fi

Alert rules:

• warning at cluster-wide CPU or memory > 75%
• critical at > 85% — new pods will fail to schedule, tenant operations will fail

Step 10: Monitor the Internal OCI Registry

Sealos uses an internal OCI image registry for app deployments. If the registry is unhealthy, application deployments and updates will fail for all tenants.

# Registry health check
curl -s http://registry.sealos-system.svc.cluster.local:5000/v2/ \
  -o /dev/null -w "%{http_code}"

Add a Vigilmon HTTP monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the registry health URL: http://<registry-endpoint>:5000/v2/
3. Set Expected HTTP status to 200.
4. Set Check interval to 2 minutes.

Alert rule: critical if the registry returns non-200 — all application deployments across all tenants are blocked.

Summary: Sealos Monitoring Checklist

| Component | Monitor Type | Alert Level | Interval | |---|---|---|---| | Kubernetes API server | HTTP | Critical | 1 min | | Sealos cloud controller | Heartbeat | Critical | 2 min | | Sealos desktop UI | HTTP | Critical | 1 min | | Tenant namespace quotas | Heartbeat | Warning/Critical | 5 min | | MinIO object storage | HTTP + Heartbeat | Critical | 1 min | | Database operator (PG/MySQL) | Heartbeat | Critical | 2 min | | Ingress controller | HTTP | Critical | 1 min | | Cert-Manager | Heartbeat | Critical | 5 min | | SSL certificate expiry | SSL | Warning/Critical | 1 day | | Cluster resource utilization | Heartbeat | Warning/Critical | 5 min | | Internal OCI registry | HTTP | Critical | 2 min |

Sealos gives your team the productivity of a public cloud platform on infrastructure you own — but that ownership means you're responsible for the entire stack. With Vigilmon watching every layer from the Kubernetes API server to per-tenant quota usage, you get the operational confidence to run a reliable private cloud for your organization.

Get started free at Vigilmon.