tutorial

How to Monitor Rancher Desktop Services with Vigilmon

Rancher Desktop is an open-source desktop application that brings local Kubernetes and container management to macOS, Windows, and Linux. It bundles `contain...

Rancher Desktop is an open-source desktop application that brings local Kubernetes and container management to macOS, Windows, and Linux. It bundles containerd, dockerd, and k3s (a lightweight Kubernetes distribution) into a single app — giving developers a full container and Kubernetes stack without needing to manage individual components.

But a local Kubernetes cluster is still a Kubernetes cluster: pods crash, services lose their endpoints, and ingresses silently fail. When you're running shared development or staging clusters on Rancher Desktop, external monitoring catches failures that kubectl get pods won't surface until you look. This tutorial shows you how to connect Vigilmon to your Rancher Desktop services.


Why monitor Rancher Desktop services?

Rancher Desktop makes it easy to spin up local Kubernetes workloads, but "easy to start" doesn't mean "easy to observe":

  • Pod crash loops — a pod restarts every 30 seconds, appears Running, but never serves traffic
  • Service endpoint failures — the Kubernetes Service exists but all backing pods are unscheduled or unhealthy
  • Ingress misconfigurations — a route is defined in your ingress but the upstream service is unreachable
  • Node resource pressure — the Rancher Desktop VM runs out of memory or CPU and all workloads degrade together
  • Namespace drift — a teammate deletes a deployment or changes a ConfigMap, silently breaking dependent services

External HTTP and TCP monitoring from Vigilmon verifies that your services are reachable and responsive from outside the Rancher Desktop VM — the same signal your users would experience.


What you'll need

  • A service running in Rancher Desktop with an exposed NodePort, LoadBalancer, or port-forwarded endpoint
  • A free Vigilmon account

Step 1: Deploy a service with a health endpoint

Before setting up monitoring, deploy a workload that exposes a /health route. Here's a minimal example:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: nginx:alpine
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: default
spec:
  selector:
    app: api
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

Apply it:

kubectl apply -f deployment.yaml

Verify the service is running:

kubectl get pods,svc -n default
# NAME                       READY   STATUS    RESTARTS   AGE
# pod/api-5d9b4c8f7-x9kl2   1/1     Running   0          30s
#
# NAME         TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# service/api  NodePort   10.43.12.200   <none>        80:30080/TCP   30s

Access it at http://localhost:30080/health (Rancher Desktop exposes NodePort services on localhost).


Step 2: Expose the service for external monitoring

Vigilmon monitors from external regions, so localhost won't work directly. You have two options:

Option A: Port-forward to a public host If you're running Rancher Desktop on a VPS or a machine with a public IP, the NodePort is directly reachable at http://<your-public-ip>:30080.

Option B: Use ngrok for local testing For laptop-based development:

ngrok http 30080
# Forwarding: https://abc123.ngrok.io -> http://localhost:30080

Use the ngrok HTTPS URL as your Vigilmon monitor target.


Step 3: Set up HTTP monitoring in Vigilmon

  1. Log in to vigilmon.online and go to Monitors → New Monitor
  2. Choose HTTP / HTTPS
  3. Enter your service URL, e.g. http://203.0.113.42:30080/health
  4. Set the check interval to 1 minute
  5. Configure Expected response:
    • Status code: 200
  6. Save the monitor

Vigilmon will now probe your Rancher Desktop service from multiple regions every minute.


Step 4: Add TCP port monitoring

For services that don't speak HTTP — a PostgreSQL pod, a Redis StatefulSet, or a gRPC server — add TCP monitors:

  1. Go to Monitors → New Monitor
  2. Choose TCP Port
  3. Enter your host and port, e.g. 203.0.113.42 / 30432
  4. Save

Common Kubernetes TCP services and their typical NodePorts:

| Service | Container Port | Example NodePort | |---|---|---| | PostgreSQL | 5432 | 30432 | | Redis | 6379 | 30679 | | MySQL | 3306 | 30306 |


Step 5: Key metrics to watch

For Rancher Desktop Kubernetes clusters, focus on:

| Metric | What it catches | |---|---| | HTTP uptime | Pod crashes, readiness failures, ingress breakage | | HTTP response time | Node resource pressure, slow startup | | TCP port reachability | Service endpoint loss, NodePort failures | | Response body content | Silent application-level failures |

Vigilmon's response time history lets you see if your cluster is under memory pressure — response times will creep up before pods start crashing.


Step 6: Configure alerts

  1. Go to Alert Channels → Add Channel
  2. Choose Webhook for Slack, Discord, or PagerDuty, or Email for simpler setups
  3. Paste your webhook URL
  4. Assign the channel to your Rancher Desktop monitors
  5. Set alert trigger: after 1 failed check

For a shared development environment, route alerts to your team's #dev-alerts Slack channel so everyone knows when the cluster is unhealthy.


Step 7: Create a status page for your local cluster

If your team shares a Rancher Desktop cluster for integration testing, a status page gives everyone a single source of truth:

  1. Go to Status Pages → New Status Page
  2. Name it, e.g. "Local K8s Status"
  3. Add your HTTP and TCP monitors
  4. Publish the page and share the URL in your team Slack

Monitoring with kubectl readiness probes vs. Vigilmon

It's worth understanding the difference:

| | kubectl / liveness probes | Vigilmon | |---|---|---| | Scope | Inside the cluster | External, multi-region | | What it checks | Pod health | User-facing endpoint reachability | | Alerts | Restart policy only | Instant webhook/email alert | | History | No retention | Full response-time history | | Status page | No | Yes |

Kubernetes liveness and readiness probes keep pods cycling. Vigilmon tells you when users can't reach your service — even when all pods say Running.


Putting it all together

A production-ready Rancher Desktop monitoring setup:

# 1. Deploy workloads with readiness probes
kubectl apply -f deployment.yaml

# 2. Verify NodePort is accessible
curl http://localhost:30080/health

# 3. In Vigilmon: create HTTP monitor on http://<host>:30080/health
# 4. In Vigilmon: create TCP monitor on <host>:30432 for the database
# 5. In Vigilmon: create Slack alert channel, assign to both monitors
# 6. In Vigilmon: publish status page, share URL with team

Conclusion

Rancher Desktop puts a full Kubernetes cluster on your laptop or VPS — but running containers at scale introduces failure modes that kubectl get pods doesn't surface until you look. Vigilmon adds the external, user-facing layer of observability that Kubernetes-native health checks leave out: continuous probing from multiple regions, instant alerts, and a public status page your team can bookmark. Set it up once and you'll know about cluster outages before your users do.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →