How to Monitor Sveltos (Multi-Cluster Add-On Controller) with Vigilmon

Sveltos is a Kubernetes controller that deploys and manages add-ons — Helm charts, raw manifests, Kustomize overlays, Lua scripts — across fleets of clusters. You define ClusterProfile and Profile objects describing what should be deployed where, and Sveltos handles reconciliation across every managed cluster.

When Sveltos is healthy and clusters are in sync, everything runs quietly. When Sveltos falls behind, a deployment fails, or a managed cluster loses connectivity, your workloads can silently drift from their desired state — with no alert from Kubernetes itself.

This tutorial walks you through monitoring Sveltos-managed workloads and the Sveltos controller with Vigilmon — free tier, no credit card required.

Why Sveltos deployments need external monitoring

Sveltos manages what gets deployed to your clusters, but it doesn't monitor whether those deployed workloads are actually serving traffic. That gap creates real failure scenarios:

• Sveltos controller is degraded — ClusterProfiles stop reconciling; clusters quietly drift from the desired state
• Add-on deployment fails silently — a Helm chart install fails on one cluster while succeeding on others; you won't know unless you check ClusterSummary status
• Health check endpoint removed by an update — a Sveltos-managed Helm chart update deletes a /health route; Kubernetes probes miss this if they check a different path
• NetworkPolicy deployed by Sveltos blocks external traffic — a new ClusterProfile adds a restrictive NetworkPolicy; your service becomes unreachable from the outside
• Rollout to wrong clusters — a ClusterSelector typo causes add-ons to deploy to the wrong clusters, leaving intended targets with stale versions

Vigilmon checks your services from outside the cluster, end-to-end. It catches every one of these failure modes without relying on Kubernetes-internal probes.

What you'll need

• A Kubernetes cluster (management cluster) running the Sveltos controller
• One or more managed clusters with Sveltos agents
• At least one workload deployed by Sveltos with an HTTP health endpoint exposed externally
• A free Vigilmon account

Step 1: Verify a Sveltos-managed workload is reachable

Sveltos typically deploys workloads via ClusterProfile. After a deployment, verify the workload is accessible:

# Check ClusterSummary to confirm successful deployment
kubectl get clustersummary -n projectsveltos

# Get the external endpoint of a managed cluster's workload
kubectl get svc my-app -n production --context=managed-cluster-1
# NAME     TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
# my-app   LoadBalancer   10.100.0.10     203.0.113.30    80:30080/TCP

Test the health endpoint:

curl http://203.0.113.30/health
# {"status":"ok","version":"1.4.2"}

If you have a domain name:

curl https://app.example.com/health
# {"status":"ok","version":"1.4.2"}

Step 2: Add HTTP monitors for Sveltos-managed workloads

1. Sign in at vigilmon.online and go to Monitors → New Monitor
2. Select HTTP / HTTPS
3. Enter the URL of your workload: https://app.example.com/health
4. Set interval to 1 minute
5. Configure Expected response:
   • Status code: 200
   • (Optional) Body contains: "status":"ok"
6. Save and repeat for each cluster where Sveltos deploys this workload

When Sveltos deploys a broken Helm chart update that breaks the health endpoint, Vigilmon detects it immediately — even if kubectl get pods shows everything Running.

Monitoring across clusters

If Sveltos manages the same workload on multiple clusters, add a monitor per cluster. Name them clearly:

• app.example.com/health — cluster-1 (us-east)
• app.example.com/health — cluster-2 (eu-west)

This lets you distinguish between a Sveltos deployment failure on one specific cluster versus a global issue.

Step 3: Monitor the Sveltos controller

The Sveltos management-cluster controller exposes metrics. If the controller itself stops processing, your fleet silently drifts.

Check what's running in the Sveltos namespace:

kubectl get pods -n projectsveltos
# NAME                                    READY   STATUS    RESTARTS   AGE
# sveltos-manager-5f8d9c7b4-xjp2m        1/1     Running   0          5d
# classifier-manager-6c8b9d4c5-krt9l     1/1     Running   0          5d
# sc-manager-7d9c8e5f6-mnp4q             1/1     Running   0          5d

If the Sveltos manager exposes an HTTP health port, add it to Vigilmon. To find any exposed ports:

kubectl get svc -n projectsveltos

For TCP connectivity monitoring of the Sveltos API server port:

1. In Vigilmon, go to Monitors → New Monitor → TCP Port
2. Enter the host and port for the Sveltos metrics or health endpoint
3. Set check interval to 1 minute
4. Save the monitor

Step 4: Use response body checks to detect version drift

A powerful Sveltos-specific monitoring technique is to include the deployed version in your workload's health response:

{
  "status": "ok",
  "version": "1.4.2",
  "deployed_by": "sveltos",
  "cluster": "us-east-1"
}

In Vigilmon, use the Response body contains field to assert the expected version string. If Sveltos deploys the wrong version to a cluster — or fails to deploy an update — the version assertion fails and Vigilmon fires an alert.

This gives you a lightweight deployment verification mechanism layered on top of uptime monitoring.

Step 5: Check ClusterSummary status in your alerting workflow

When Vigilmon fires an alert about a Sveltos-managed workload, your first diagnostic step should be to check whether the Sveltos deployment itself is healthy:

# Check overall deployment status across clusters
kubectl get clustersummary -A

# Get details for a specific profile
kubectl describe clustersummary <name> -n projectsveltos

# Check for Sveltos events
kubectl get events -n projectsveltos --sort-by='.lastTimestamp' | tail -20

Common Sveltos failure signatures:

# Helm chart deployment failures appear here
kubectl get helmchartrequest -A

# ClusterProfile reconciliation errors
kubectl logs -n projectsveltos -l app=sveltos-manager --tail=100 | grep -E "ERROR|failed|reconcile"

Use this output to determine whether the issue is in the workload itself (application bug) or in Sveltos deployment (controller or chart error).

Step 6: Configure alert routing

1. In Vigilmon, go to Alert Channels → Add Channel
2. Choose Webhook for Slack or PagerDuty integration, or Email for direct notification
3. Assign channels to your Sveltos-related monitors

For platform teams managing large Sveltos fleets, a dedicated Slack channel for Sveltos alerts makes it easy to correlate Vigilmon alerts with Sveltos reconciliation events.

Example Slack message from a Vigilmon webhook alert:

🔴 DOWN — app.example.com/health (cluster-2, eu-west)
Status: 503 Service Unavailable
Duration: 3 minutes

When you see this, immediately check:

kubectl get clustersummary -n projectsveltos | grep cluster-2
kubectl describe clustersummary <summary-name> -n projectsveltos

Step 7: Build a fleet health status page

1. In Vigilmon, go to Status Pages → New Status Page
2. Name it "Sveltos Fleet Health" or your cluster group name
3. Add monitors for each cluster's workloads
4. Group by cluster, region, or workload type
5. Publish the page

Share this page with your platform engineering team and dependent teams. When Sveltos rolls out an update to multiple clusters, team members can watch the status page to confirm each cluster goes green after deployment.

Monitoring summary

| Monitor | Type | What it detects | |---------|------|-----------------| | Workload HTTP endpoint per cluster | HTTP | App serving traffic after Sveltos deployment | | Response body version assertion | HTTP | Correct version deployed by Sveltos | | Sveltos controller health port | TCP | Controller liveness | | Cluster-specific endpoints | HTTP | Cluster-specific deployment failures |

What's next

• Heartbeat monitoring — if you run Sveltos-managed CronJobs or batch workloads, use Vigilmon heartbeats to detect when scheduled jobs stop checking in
• SSL monitoring — Vigilmon tracks TLS certificates on your managed-cluster workloads; useful when cert-manager is itself a Sveltos-managed add-on
• Latency baselines — use Vigilmon's response time history to establish per-cluster latency baselines; spikes after a Sveltos deployment indicate the update degraded performance

Get started free at vigilmon.online — no credit card, monitors start running in under a minute.