Monitoring Karpor with Vigilmon: Keeping Your Multi-Cluster Intelligence Platform Available

Karpor is a Kubernetes intelligence platform that provides unified resource search, topology visualization, and compliance governance across fleets of clusters. Platform teams use Karpor to query every resource across every cluster from a single API, explore cross-cluster dependencies, and continuously audit workloads against compliance policies. When Karpor's API server is unavailable, engineers lose visibility into cluster state and compliance drift goes undetected. When the search indexer falls behind, queries return stale data that masks real cluster conditions. Vigilmon gives you external monitoring that watches Karpor's API surface and validates that its background sync and compliance jobs are completing on schedule.

What You'll Build

• Vigilmon HTTP monitors for the Karpor API server and search endpoints
• A heartbeat monitor validating that multi-cluster resource sync is completing
• A compliance scan job heartbeat to catch silent scan failures
• Alert channels routed to your platform engineering team

Prerequisites

• Karpor deployed in your Kubernetes environment (hub cluster)
• At least one spoke cluster registered with Karpor
• A free account at vigilmon.online

Why Monitoring Karpor Matters

Karpor sits in the critical path for platform observability and compliance. Its failure modes surface slowly and are easy to miss:

API server unavailability leaves engineers unable to search or inspect cross-cluster resources. If Karpor is the authoritative source for compliance dashboards or developer self-service portals, an unmonitored outage means teams fly blind — often not discovering the problem until someone notices dashboards are stale.

Search indexer lag is a subtler problem. Karpor maintains a search index synchronized from spoke cluster API servers. If the indexer falls behind, query results show outdated resource state. A deleted pod still appears as running; a misconfigured deployment that was patched appears unchanged. Without a heartbeat monitor on the sync job, indexer lag is invisible until a developer acts on stale data.

Compliance scan failures are the most dangerous silent failure. Karpor continuously evaluates workloads against compliance rule sets. A compliance scan job that crashes or hangs stops producing new violation findings — and operators assume the clean dashboard means compliant workloads, not a broken scanner.

Cluster sync disruption occurs when Karpor loses connectivity to a spoke cluster. New resources in that cluster stop appearing in search results. Cross-cluster topology views become incomplete. External monitoring that validates sync liveness catches this before it affects incident response.

Step 1: Monitor the Karpor API Server

Karpor exposes a REST API server (default port 7443). Monitor its health endpoint to confirm the API is accepting requests:

# Verify the Karpor API server is reachable
curl -k https://karpor.yourdomain.com/livez
# Expected: {"status":"ok"}

In the Vigilmon dashboard:

1. Go to Add Monitor → HTTP
2. Configure:

| Field | Value | |---|---| | Name | Karpor API /livez | | URL | https://karpor.yourdomain.com/livez | | Method | GET | | Expected status | 200 | | Response body contains | ok | | Check interval | 1 minute | | Timeout | 10 seconds | | Alert after | 2 consecutive failures |

If Karpor is exposed via an ingress or internal load balancer, replace the hostname accordingly. The /livez endpoint responds without authentication and is the canonical liveness signal for the API server process.

Step 2: Monitor the Karpor Search API

The search API is the primary interface engineers use to query cross-cluster resources. Add a dedicated probe to validate that search is functioning:

# Test the search API with a simple query
curl -sk https://karpor.yourdomain.com/rest-api/v1/search?query=kind:Pod \
  -H "Authorization: Bearer $KARPOR_TOKEN" | head -c 200
# Expected: {"success":true,"data":{"resources":[...],"total":...}}

In Vigilmon:

| Field | Value | |---|---| | Name | Karpor search API | | URL | https://karpor.yourdomain.com/rest-api/v1/search?query=kind:Pod | | Method | GET | | Request headers | Authorization: Bearer YOUR_READ_TOKEN | | Expected status | 200 | | Response body contains | success | | Check interval | 2 minutes | | Timeout | 15 seconds | | Alert after | 2 consecutive failures |

A probe failure here but not on /livez indicates the search indexer is down while the API server is alive — a common split-brain failure mode worth distinguishing in your alerts.

Step 3: Heartbeat Monitor for Cluster Sync

Karpor continuously synchronizes resources from spoke clusters into its storage backend. Add a heartbeat that a CronJob pings after verifying sync liveness:

# karpor-sync-probe.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: karpor-sync-probe
  namespace: karpor
spec:
  schedule: "*/10 * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: sync-probe
              image: curlimages/curl:latest
              env:
                - name: KARPOR_URL
                  value: "https://karpor.yourdomain.com"
                - name: KARPOR_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: karpor-monitoring
                      key: token
                - name: HEARTBEAT_URL
                  valueFrom:
                    secretKeyRef:
                      name: vigilmon-secrets
                      key: karpor-sync-heartbeat-url
              command:
                - /bin/sh
                - -c
                - |
                  set -e

                  # Verify the search index has been updated recently
                  # by checking that at least one cluster's resources appear
                  RESULT=$(curl -sf --max-time 30 \
                    -H "Authorization: Bearer $KARPOR_TOKEN" \
                    "$KARPOR_URL/rest-api/v1/search?query=kind:Node&pageSize=1")

                  TOTAL=$(echo "$RESULT" | grep -o '"total":[0-9]*' | cut -d: -f2)

                  if [ -n "$TOTAL" ] && [ "$TOTAL" -gt 0 ]; then
                    echo "Sync probe: $TOTAL nodes found in index"
                    wget -qO- "$HEARTBEAT_URL"
                    echo "Heartbeat sent"
                  else
                    echo "ERROR: No nodes found in index — sync may be stalled" >&2
                    exit 1
                  fi

Create the heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat
2. Name: Karpor cluster sync
3. Expected interval: 10 minutes
4. Grace period: 5 minutes

Store the secrets:

kubectl create secret generic vigilmon-secrets \
  --from-literal=karpor-sync-heartbeat-url='https://vigilmon.online/heartbeat/YOUR_SYNC_TOKEN' \
  --from-literal=karpor-compliance-heartbeat-url='https://vigilmon.online/heartbeat/YOUR_COMPLIANCE_TOKEN' \
  -n karpor

kubectl create secret generic karpor-monitoring \
  --from-literal=token='YOUR_KARPOR_READ_TOKEN' \
  -n karpor

Step 4: Heartbeat Monitor for Compliance Scans

Karpor runs compliance scans on a schedule to evaluate workloads against rule sets. Monitor that scans are completing:

# karpor-compliance-probe.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: karpor-compliance-probe
  namespace: karpor
spec:
  schedule: "0 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: compliance-probe
              image: curlimages/curl:latest
              env:
                - name: KARPOR_URL
                  value: "https://karpor.yourdomain.com"
                - name: KARPOR_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: karpor-monitoring
                      key: token
                - name: HEARTBEAT_URL
                  valueFrom:
                    secretKeyRef:
                      name: vigilmon-secrets
                      key: karpor-compliance-heartbeat-url
              command:
                - /bin/sh
                - -c
                - |
                  set -e

                  # Query compliance report API to verify scans have run
                  RESULT=$(curl -sf --max-time 30 \
                    -H "Authorization: Bearer $KARPOR_TOKEN" \
                    "$KARPOR_URL/rest-api/v1/insight/score" 2>&1)

                  if echo "$RESULT" | grep -q "score"; then
                    echo "Compliance scan results available"
                    wget -qO- "$HEARTBEAT_URL"
                    echo "Compliance heartbeat sent"
                  else
                    echo "ERROR: Compliance score API returned unexpected response" >&2
                    echo "Response: $RESULT" >&2
                    exit 1
                  fi

Create the heartbeat monitor in Vigilmon:

1. Add Monitor → Heartbeat
2. Name: Karpor compliance scans
3. Expected interval: 1 hour
4. Grace period: 15 minutes

Step 5: Configure Alert Channels

Route Karpor alerts to your platform engineering team:

1. In Vigilmon: Alert Channels → Add Channel → Slack Webhook
2. Add your #platform-engineering webhook URL
3. Assign to all Karpor monitors

For compliance scan failures (a silent compliance failure is a security concern):

1. Alert Channels → Add Channel → Email
2. Add your security or platform team's on-call address
3. Assign specifically to the Karpor compliance scans heartbeat

What You're Now Monitoring

| Component | Monitor Type | What It Detects | |---|---|---| | Karpor API /livez | HTTP GET | API server process down, ingress unreachable | | Karpor search API | HTTP GET | Search indexer crashed, query path broken | | Cluster sync | Heartbeat (10 min) | Resource sync stalled, spoke cluster connectivity lost | | Compliance scans | Heartbeat (1 hour) | Compliance scanner crashed, stale violation data |

Conclusion

Karpor's value to a platform team is proportional to its availability and data freshness — a stale or unavailable Karpor is worse than no Karpor, because teams may act on incorrect cluster state. External monitoring with Vigilmon closes the observability gap by watching Karpor's API from outside the cluster and validating that its background sync and compliance pipelines are keeping pace.

Get started free at vigilmon.online. The API liveness probe and sync heartbeat together give you the two most critical Karpor signals in under ten minutes: is the API serving requests, and is the search index current?