tutorial

Monitoring SuperEdge on Kubernetes with Vigilmon

SuperEdge extends Kubernetes to distributed edge nodes with autonomous operation during cloud disconnects — but when tunnels drop or the lite-apiserver fails, edge nodes lose their autonomy guarantee. Here's how to monitor SuperEdge's control plane, tunnels, and edge node health with Vigilmon.

SuperEdge lets Kubernetes manage edge nodes across geographically distributed sites, keeping workloads running even when the cloud control plane is temporarily unreachable. But when a SuperEdge tunnel silently disconnects or a lite-apiserver crashes on an edge node, that edge node loses its autonomy guarantee — and the cloud control plane can no longer reach it for kubectl exec, log streaming, or metrics collection. Vigilmon fills that gap with heartbeat monitors for the SuperEdge cloud components, edge tunnels, lite-apiserver processes, and ServiceGroup health.

What You'll Set Up

  • SuperEdge cloud controller uptime monitor
  • Tunnel connectivity check per edge node
  • lite-apiserver health check on edge nodes
  • Edge node readiness percentage tracking
  • ServiceGroup reconciliation health monitor
  • Edge-to-cloud latency alerting

Prerequisites

  • SuperEdge installed on a Kubernetes cluster (cloud control plane + edge nodes)
  • kubectl access to the cloud cluster
  • SSH or agent access to edge nodes for local health checks
  • A free Vigilmon account

Step 1: Monitor the SuperEdge Cloud Controller

The superedge-controller-manager manages edge node lifecycle, ServiceGroup reconciliation, and edge node status. If it crashes, edge nodes stop receiving updates and ServiceGroup configurations drift out of sync.

  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 2 minutes.
  3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Create a Kubernetes CronJob in the cloud cluster:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: superedge-controller-health
  namespace: edge-system
spec:
  schedule: "*/2 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: superedge-health-checker
          containers:
          - name: checker
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              READY=$(kubectl get deployment superedge-controller-manager \
                -n edge-system \
                -o jsonpath='{.status.readyReplicas}' 2>/dev/null)
              if [ "${READY:-0}" -ge 1 ]; then
                wget -q -O- https://vigilmon.online/heartbeat/abc123
              fi
          restartPolicy: OnFailure

Apply the RBAC needed for the health checker ServiceAccount to read Deployments in the edge-system namespace.

Step 2: Monitor SuperEdge Tunnel Connectivity

SuperEdge's tunnel component maintains encrypted WebSocket connections between the cloud control plane and each edge node, enabling kubectl exec, log streaming, and metrics scraping to work across NAT/firewalls without public IPs on edge nodes. A tunnel disconnection for a production edge node means operators lose the ability to debug, exec into pods, or stream logs from that site.

Check tunnel pod health in the cloud cluster:

#!/bin/bash
# superedge-tunnel-health.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/def456"
NAMESPACE="edge-system"

# Check cloud-side tunnel pods
DESIRED=$(kubectl get daemonset tunnel-cloud -n "$NAMESPACE" \
  -o jsonpath='{.status.desiredNumberScheduled}' 2>/dev/null)
READY=$(kubectl get daemonset tunnel-cloud -n "$NAMESPACE" \
  -o jsonpath='{.status.numberReady}' 2>/dev/null)

if [ "${DESIRED:-0}" -gt 0 ] && [ "${READY}" -eq "${DESIRED}" ]; then
  curl -s "$HEARTBEAT_URL"
fi

For per-node tunnel connectivity, run this script on each edge node (via SSH or a local agent):

#!/bin/bash
# edge-tunnel-check.sh — runs on each edge node

HEARTBEAT_URL="https://vigilmon.online/heartbeat/ghi789"

# Check if tunnel-edge process is running and connected
TUNNEL_PID=$(pgrep -f tunnel-edge)
if [ -n "$TUNNEL_PID" ]; then
  # Verify tunnel is connected by checking if lite-apiserver can reach cloud
  if kubectl --kubeconfig=/etc/kubernetes/edge/kubeconfig get nodes &>/dev/null; then
    curl -s "$HEARTBEAT_URL"
  fi
fi

Create a separate Vigilmon heartbeat per production edge node. A missed heartbeat from a single edge node tells you exactly which site lost tunnel connectivity.

Step 3: Monitor lite-apiserver on Edge Nodes

The lite-apiserver is SuperEdge's key edge autonomy mechanism — a lightweight API server proxy running on each edge node that caches Kubernetes API responses locally. When the cloud control plane is unreachable, kubelet and other edge components continue operating by reading from the lite-apiserver cache. If the lite-apiserver crashes, the edge node loses all Kubernetes API access and workloads can no longer be scheduled or managed locally.

Add an HTTP monitor for each edge node's lite-apiserver:

  1. Add a monitor → HTTP / HTTPS (or use TCP Port if the health endpoint isn't accessible from Vigilmon's cloud probes).
  2. Enter: https://EDGE_NODE_IP:51003/healthz (lite-apiserver default port is 51003).
  3. Set Expected HTTP status to 200.
  4. Set Check interval to 1 minute.
  5. Click Save.

For edge nodes not directly accessible from the internet, use a local health check script with a cron heartbeat instead:

#!/bin/bash
# lite-apiserver-health.sh — runs on edge node

HEARTBEAT_URL="https://vigilmon.online/heartbeat/jkl012"

# Check lite-apiserver health
HTTP_STATUS=$(curl -sk -o /dev/null -w "%{http_code}" \
  https://localhost:51003/healthz 2>/dev/null)

if [ "$HTTP_STATUS" -eq 200 ]; then
  curl -s "$HEARTBEAT_URL"
fi

Deploy this script via SuperEdge itself as a workload on each edge node, or via a systemd timer alongside the lite-apiserver process.

Step 4: Edge Node Readiness Percentage

The most important fleet-level metric for SuperEdge is the percentage of edge nodes reporting Ready to the cloud control plane. A sudden drop from 100% to 60% indicates a network event affecting a geographic region or a SuperEdge component failure causing mass node status updates to stall.

#!/bin/bash
# edge-node-readiness.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/mno345"
MIN_READY_PCT=90  # alert if fewer than 90% of edge nodes are Ready

TOTAL=$(kubectl get nodes -l node-role.kubernetes.io/edge="" \
  --no-headers 2>/dev/null | wc -l)

READY=$(kubectl get nodes -l node-role.kubernetes.io/edge="" \
  --no-headers 2>/dev/null | grep " Ready " | wc -l)

if [ "${TOTAL:-0}" -gt 0 ]; then
  PCT=$(( READY * 100 / TOTAL ))
  echo "Edge nodes ready: $READY/$TOTAL ($PCT%)"
  if [ "$PCT" -ge "$MIN_READY_PCT" ]; then
    curl -s "$HEARTBEAT_URL"
  fi
fi

Run this in a Kubernetes CronJob in the cloud cluster every 2 minutes. If readiness drops below your threshold, Vigilmon alerts.

For individual edge node alerting (any single production node NotReady for >5 minutes):

#!/bin/bash
# edge-node-individual-check.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/pqr678"
MAX_NOTREADY_MINUTES=5

# Find edge nodes that have been NotReady for more than N minutes
NOTREADY=$(kubectl get nodes -l node-role.kubernetes.io/edge="" \
  -o json 2>/dev/null | \
  jq --argjson max_minutes "$MAX_NOTREADY_MINUTES" \
  '[.items[] | .status.conditions[] | 
   select(.type=="Ready" and .status=="False") |
   select(
     (now - (.lastTransitionTime | fromdateiso8601)) > ($max_minutes * 60)
   )] | length')

if [ "${NOTREADY:-0}" -eq 0 ]; then
  curl -s "$HEARTBEAT_URL"
fi

Step 5: Monitor ServiceGroup Health

SuperEdge's ServiceGroup CRD enables edge-site-local traffic steering — keeping requests within the same geographic edge site rather than routing them to the cloud. ServiceGroup reconciliation failures cause traffic to fall through to non-local endpoints, defeating the edge locality goal and potentially increasing latency significantly.

#!/bin/bash
# servicegroup-health.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/stu901"

# Check for ServiceGroups in a non-Ready state
NOT_READY=$(kubectl get servicegroups --all-namespaces \
  -o jsonpath='{.items[*].status.phase}' 2>/dev/null | \
  tr ' ' '\n' | grep -cv "Ready" || echo 0)

if [ "${NOT_READY}" -eq 0 ]; then
  curl -s "$HEARTBEAT_URL"
fi

If your SuperEdge version doesn't expose ServiceGroup status in status.phase, check for reconciliation errors in the controller logs instead:

ERRORS=$(kubectl logs -n edge-system \
  deployment/superedge-controller-manager \
  --since=5m 2>/dev/null | grep -c "servicegroup.*reconcil.*error" || echo 0)

if [ "${ERRORS}" -eq 0 ]; then
  curl -s "$HEARTBEAT_URL"
fi

Step 6: Edge-to-Cloud Tunnel Latency

High tunnel latency means kubectl exec, log streaming, and metrics collection become sluggish. Alert on P95 tunnel latency exceeding 500ms to catch WAN congestion before it impacts operator productivity:

#!/bin/bash
# tunnel-latency-check.sh — runs on edge node

HEARTBEAT_URL="https://vigilmon.online/heartbeat/vwx234"
MAX_LATENCY_MS=500
CLOUD_API="https://your-cloud-k8s-api:6443"

# Measure round-trip time through the tunnel to the cloud API
START=$(date +%s%3N)
curl -sk -o /dev/null "$CLOUD_API/healthz" 2>/dev/null
END=$(date +%s%3N)

RTT=$(( END - START ))
echo "Tunnel RTT: ${RTT}ms"

if [ "$RTT" -lt "$MAX_LATENCY_MS" ]; then
  curl -s "$HEARTBEAT_URL"
fi

Run every 5 minutes from each edge node. If WAN congestion pushes latency above 500ms, the heartbeat pauses and Vigilmon alerts.

Step 7: Edge Workload Health per Site

Monitor the health of workloads deployed to edge sites. A pod crash-looping on an edge node may not be immediately visible in the cloud control plane dashboard if connectivity is degraded:

#!/bin/bash
# edge-workload-health.sh

HEARTBEAT_URL="https://vigilmon.online/heartbeat/yza567"
EDGE_NAMESPACE="production"

# Check for crash-looping pods on edge nodes
CRASHLOOPS=$(kubectl get pods -n "$EDGE_NAMESPACE" \
  -o json 2>/dev/null | \
  jq '[.items[] | 
    select(.spec.nodeName | test("edge-")) |
    select(.status.containerStatuses[]?.state.waiting?.reason == "CrashLoopBackOff")
  ] | length')

if [ "${CRASHLOOPS:-0}" -eq 0 ]; then
  curl -s "$HEARTBEAT_URL"
fi

Step 8: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and configure Slack, PagerDuty, or webhook.
  2. Set Consecutive failures before alert:
    • SuperEdge controller: 1 — controller downtime needs immediate response
    • Tunnel pods: 2 — allow one reconnect cycle
    • lite-apiserver: 1 — crash means loss of edge autonomy immediately
    • Edge node readiness: 2 — allow one reconcile cycle before alerting
    • Tunnel latency: 3 — brief WAN spikes are normal
  3. Name monitors with site identifiers (e.g., "SuperEdge Tunnel: US-East-Site-3") so on-call responders can immediately identify affected locations.
  4. Use Maintenance windows when performing planned edge node maintenance or SuperEdge upgrades:
# Before edge node maintenance
curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "edge-node-xyz-id", "duration_minutes": 30}'

Summary

| Monitor | Target | What It Catches | |---|---|---| | Cloud controller | Deployment readyReplicas | Edge lifecycle management failure | | Tunnel cloud pods | DaemonSet completeness | All edge tunnels affected | | Tunnel per-node | Cron heartbeat per edge site | Individual site disconnection | | lite-apiserver | HTTP :51003/healthz per node | Edge autonomy loss | | Edge node readiness | Cron heartbeat every 2 min | Network event, mass node failure | | ServiceGroup | Cron heartbeat every 5 min | Traffic locality failure | | Tunnel latency | Cron heartbeat every 5 min | WAN congestion impacting operators | | Edge workloads | Cron heartbeat per namespace | Per-site crash-loop detection |

SuperEdge's edge autonomy guarantee is only as good as the tunnel, lite-apiserver, and controller staying healthy. With Vigilmon watching each layer — from the cloud controller to the per-node lite-apiserver — you'll catch connectivity failures and autonomy breakdowns before your edge sites start running in a degraded, unmonitored state.

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