How to Monitor CloudCasa with Vigilmon (HTTP + TCP + Alerts)

CloudCasa is a cloud-native backup-as-a-service platform for Kubernetes clusters, offering automated backup, disaster recovery, and cluster migration from a centralized web interface at cloudcasa.io. Its agent-based architecture places a lightweight cloudcasa-agent deployment inside each Kubernetes cluster, which connects outbound over HTTPS to the CloudCasa SaaS control plane at api.cloudcasa.io. The agent handles local data movement and snapshot orchestration while all backup scheduling, policy management, and reporting live in the CloudCasa cloud — meaning either side of that agent-to-control-plane connection failing will silently break your backups.

In this tutorial you'll set up comprehensive uptime monitoring for CloudCasa — covering the in-cluster agent, the SaaS control plane, and your storage backend — using Vigilmon — free tier, no credit card required.

Why CloudCasa needs external monitoring

CloudCasa spans two domains: your Kubernetes cluster and a remote SaaS control plane. Standard cluster health checks only report what's running, not whether backups are actually completing:

• Agent pod crash — the cloudcasa-agent deployment in the cloudcasa namespace restarts or enters CrashLoopBackOff; the cluster stops reporting to the CloudCasa control plane and backups silently fail with no local Kubernetes event surfaced to the namespace owner
• CloudCasa SaaS control plane outage — the in-cluster agent is healthy and running, but api.cloudcasa.io is unreachable or degraded; all backup scheduling and policy enforcement stops because the agent receives no instructions
• Agent loses outbound connectivity to cloudcasa.io — a network policy change or egress firewall rule blocks the agent's HTTPS connection to the control plane; backup jobs queue at the control plane but never execute locally, leaving clusters unprotected with no visible error
• Storage backend unreachable — the agent reports healthy and receives scheduling instructions, but the underlying object store or snapshot target is unavailable; backup jobs start but data writes fail mid-transfer, producing corrupt or incomplete restore points
• RBAC or namespace permissions change — a cluster policy update removes the cloudcasa-agent ServiceAccount's permissions to list or access namespaces, pods, or PVCs it needs to back up; the agent runs but silently skips protected resources

External monitoring from multiple geographic regions catches failures spanning the agent, the SaaS control plane, and the storage path simultaneously.

What you'll need

• A Kubernetes cluster with the CloudCasa agent installed (the cloudcasa-agent deployment in the cloudcasa namespace)
• A CloudCasa account at cloudcasa.io with at least one cluster registered
• A free Vigilmon account (sign up takes 30 seconds)

Step 1: Expose CloudCasa agent health endpoints

The CloudCasa agent exposes an HTTP health endpoint on port 8080 inside the cluster. Expose it externally via NodePort so Vigilmon can reach it:

# cloudcasa-agent-health-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: cloudcasa-agent-health
  namespace: cloudcasa
spec:
  type: NodePort
  selector:
    app: cloudcasa-agent
  ports:
    - name: healthz
      port: 8080
      targetPort: 8080
      nodePort: 30808
      protocol: TCP

Apply the service:

kubectl apply -f cloudcasa-agent-health-svc.yaml

Verify the agent health endpoint responds:

curl http://<node-ip>:30808/healthz
# {"status":"ok"}

Confirm the agent pod is running and ready:

kubectl get deployment -n cloudcasa cloudcasa-agent
# NAME               READY   UP-TO-DATE   AVAILABLE   AGE
# cloudcasa-agent    1/1     1            1           12d

kubectl get pods -n cloudcasa -l app=cloudcasa-agent
# NAME                               READY   STATUS    RESTARTS   AGE
# cloudcasa-agent-7d9f8b6c5-xk2pq   1/1     Running   0          2d

Note that the agent connects outbound to api.cloudcasa.io:443 using HTTPS. No inbound firewall rules are required on the agent side — only the NodePort you created for Vigilmon's health checks.

Step 2: Set up HTTP monitoring in Vigilmon

With the agent health endpoint exposed, add CloudCasa to Vigilmon:

Monitor the in-cluster agent

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to http://<node-ip>:30808/healthz
4. Set the check interval to 1 minute
5. Under Expected response, set:
   • Status code: 200
   • Response body contains: ok
6. Name the monitor cloudcasa-agent /healthz
7. Save the monitor

Monitor the CloudCasa SaaS control plane

CloudCasa's control plane is the authoritative source of backup schedules and policies. Monitor its availability directly:

1. Go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to https://api.cloudcasa.io/health
4. Set the check interval to 1 minute
5. Under Expected response, set:
   • Status code: 200
6. Name the monitor CloudCasa Control Plane (api.cloudcasa.io)
7. Save the monitor

The multi-region consensus advantage

Vigilmon probes your endpoints from multiple geographic regions simultaneously. Because CloudCasa health depends on both the in-cluster agent and the remote SaaS control plane, a single probe failure could reflect a transient network path issue rather than a real outage. Vigilmon's multi-region consensus requires multiple independent probes to agree before triggering an alert — giving you accurate detection without false positives on either the agent or the control plane.

Step 3: Monitor your TCP layer

TCP monitoring catches connectivity failures at the network layer before they surface as HTTP errors or missed backup windows.

In Vigilmon:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your node IP and port 30808 (agent health NodePort)
4. Name it cloudcasa-agent TCP
5. Save the monitor
6. Add a second TCP monitor for api.cloudcasa.io on port 443 — this verifies the SaaS control plane is reachable over TLS from Vigilmon's probe locations
7. If you use an on-premises or self-hosted object storage backend (e.g., MinIO on port 9000, or an NFS server on port 2049), add TCP monitors for those endpoints as well

# Verify agent outbound connectivity to CloudCasa control plane from a cluster node
kubectl run cloudcasa-netcheck --image=busybox --rm -it --restart=Never -- \
  sh -c "nc -zv api.cloudcasa.io 443"
# Connection to api.cloudcasa.io 443 port [tcp/https] succeeded!

# Verify local storage backend reachability (example: MinIO)
kubectl run storage-netcheck --image=busybox --rm -it --restart=Never -- \
  sh -c "nc -zv <storage-backend-ip> 9000"

The TCP monitor for api.cloudcasa.io:443 is your earliest warning that the SaaS control plane is unreachable — it fires before any backup schedule misses its window.

Step 4: Configure alert channels

A crashed CloudCasa agent means your cluster is unprotected. A control plane outage means no backup jobs are being dispatched. You need immediate notification on both.

Email alerts

1. In Vigilmon, go to Alert Channels → Add Channel → Email
2. Enter your backup-operations or on-call email address
3. Assign the channel to all your CloudCasa monitors (agent HTTP, agent TCP, control plane HTTP, control plane TCP)

Webhook alerts (Slack, PagerDuty, etc.)

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your webhook URL
3. Assign the channel to your monitors

Example payload Vigilmon sends when a monitor goes down:

{
  "monitor_name": "cloudcasa-agent /healthz",
  "status": "down",
  "url": "http://203.0.113.50:30808/healthz",
  "started_at": "2024-03-10T04:15:00Z",
  "duration_seconds": 120
}

When you receive a CloudCasa alert, run these kubectl diagnostics to pinpoint the failure:

# Check the agent pod status and restart count
kubectl get pods -n cloudcasa -l app=cloudcasa-agent -o wide

# Inspect agent logs for control plane connection errors
kubectl logs -n cloudcasa deploy/cloudcasa-agent --tail=100 | grep -i "error\|failed\|disconnect\|timeout"

# Check agent events for OOMKill or scheduling issues
kubectl describe pod -n cloudcasa -l app=cloudcasa-agent | tail -30

# Verify outbound connectivity to the CloudCasa control plane from the agent pod
kubectl exec -n cloudcasa deploy/cloudcasa-agent -- \
  sh -c "curl -sv https://api.cloudcasa.io/health 2>&1 | tail -5"

# Check the agent ServiceAccount and RBAC bindings
kubectl get clusterrolebinding | grep cloudcasa
kubectl auth can-i list pods --as=system:serviceaccount:cloudcasa:cloudcasa-agent -A

Step 5: Create a public status page

Backup health is a cross-team concern — developers want to know their namespaces are protected without needing kubectl access. A public status page surfaces CloudCasa health for everyone.

1. In Vigilmon, go to Status Pages → New Status Page
2. Give it a name: "CloudCasa Backup Infrastructure"
3. Add your monitors and group them:
   • CloudCasa Agent — agent HTTP health, agent TCP
   • CloudCasa Control Plane — api.cloudcasa.io HTTP, api.cloudcasa.io:443 TCP
   • Backup Storage — storage backend TCP monitors (object store, NFS, etc.)
4. Publish the page

Share the status page URL in your runbook, backup policy documentation, and with application teams whose namespaces are protected by CloudCasa.

Putting it all together

Here's a summary of the monitors to create for a CloudCasa deployment:

| Monitor | Type | What it catches | |---------|------|-----------------| | http://<node-ip>:30808/healthz | HTTP | Agent crash loops, OOMKill, pod eviction | | <node-ip>:30808 | TCP | Agent NodePort reachability | | https://api.cloudcasa.io/health | HTTP | SaaS control plane outage, API degradation | | api.cloudcasa.io:443 | TCP | Control plane TLS connectivity — earliest warning for backup schedule failures | | <storage-backend-ip>:<port> | TCP | Object store or NFS backend reachability — catches mid-transfer data write failures |

Verify the full CloudCasa agent state in your cluster:

# List all resources in the cloudcasa namespace
kubectl get all -n cloudcasa

# Check the agent deployment rollout status
kubectl rollout status deploy/cloudcasa-agent -n cloudcasa

# View recent agent events
kubectl get events -n cloudcasa --sort-by='.lastTimestamp' | tail -20

# Confirm the agent's ServiceAccount exists and has correct annotations
kubectl get serviceaccount -n cloudcasa cloudcasa-agent -o yaml

# List ClusterRoles bound to the cloudcasa-agent ServiceAccount
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.subjects[]?.name=="cloudcasa-agent" and .subjects[]?.namespace=="cloudcasa") | .metadata.name'

What's next

• Monitor multiple clusters — register each Kubernetes cluster in CloudCasa and create a separate agent health monitor per cluster in Vigilmon; group them by cluster name on your status page to see protection coverage at a glance
• Heartbeat monitors for backup completion webhooks — CloudCasa can send a webhook after each successful backup job; configure Vigilmon's heartbeat monitors on those endpoints so you're alerted when a backup window is missed without a completion ping
• Alerting on missed backup windows — combine Vigilmon's heartbeat monitors with your backup schedule (daily, hourly) so a missed window triggers an alert within minutes rather than being discovered at restore time

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