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

Retina is Microsoft's eBPF-based Kubernetes network observability platform that provides deep packet-level visibility into network flows, latency, and connectivity across your cluster — all without modifying application code. Its control plane and metrics endpoints are the backbone of your network observability stack: if the Retina agent DaemonSet degrades or the metrics server becomes unreachable, engineers lose real-time visibility into network health and troubleshooting investigations stall. Vigilmon adds the external perspective that Retina cannot provide for itself: continuous uptime and latency checks from outside your infrastructure that keep watching even when the observability platform is the component that has failed. You can add your first monitor for free, no credit card required.

Why Retina needs external monitoring

eBPF program load failure silently disables network visibility. Retina loads eBPF programs into the Linux kernel on each node at startup. If the kernel version is incompatible, the BTF CO-RE relocation fails, or the BPF filesystem is unavailable, the agent starts but falls back to a degraded mode that collects no packet data. The agent process stays alive and the pod appears healthy, but all network flow metrics go to zero — engineers see flat lines in dashboards and may incorrectly conclude the cluster has zero network activity rather than that the observability layer has failed silently.
Metrics endpoint failure breaks all downstream consumers simultaneously. Retina exposes Prometheus-compatible metrics on a dedicated port that Prometheus, Grafana, and other consumers scrape. If this endpoint crashes or stops responding — due to a port conflict, OOM kill of the metrics goroutine, or panic in the metrics aggregation pipeline — every dashboard and alert that depends on network metrics goes stale at the same moment. Because the failure is in the metrics collection layer itself, no dashboard alert fires, and the outage is only discovered when engineers notice stale data.
Node-level agent crashes create invisible network monitoring gaps. Retina runs as a DaemonSet, deploying one agent per node. If an agent crashes on several nodes — due to kernel upgrades, CRI changes, or eBPF map exhaustion — the cluster retains network visibility only for the nodes where agents are still running. Engineers examining network flows see partial data that appears complete, leading to incorrect root-cause analysis during incidents. An external health monitor on the metrics endpoint detects degradation before it misleads an investigation.
TLS certificate expiry on the metrics endpoint breaks all Prometheus scrapers. If the Retina metrics endpoint is served over TLS with client certificate validation, an expired certificate causes every Prometheus scraper to fail simultaneously with TLS handshake errors. Prometheus stops receiving network metrics across the entire cluster and existing alert rules begin misfiring because their underlying time series stop updating. An external SSL monitor catches the expiry days before it disrupts the metrics pipeline.
Kubernetes API connectivity loss prevents the agent from reconciling network policies. The Retina control plane connects to the Kubernetes API server to watch NetworkPolicy, Pod, and Namespace objects and translate them into eBPF rules. If the API server becomes unreachable from the node where the Retina agent runs — network partition, RBAC change, or expired ServiceAccount token — the agent continues collecting metrics for existing connections but stops tracking new pods and policy changes. This creates a growing divergence between the actual network state and what Retina reports. An external HTTP monitor cannot detect this directly, but monitoring the metrics endpoint for consistent data update timestamps surfaces agent stalls indirectly.

What you'll need

A running Retina deployment with its metrics endpoint accessible over HTTPS
The public hostname or IP for your Retina metrics endpoint, for example https://retina.example.com
A free Vigilmon account — monitors start running in under a minute with no credit card required

Step 1: Expose Retina's health and metrics endpoints

Verify your Retina installation is reachable and locate the health and metrics endpoints before configuring Vigilmon monitors.

# Check Retina operator health endpoint
curl -I https://retina.example.com/healthz

# Sample output:
# HTTP/2 200
# content-type: text/plain; charset=utf-8

# Verify the metrics endpoint is responding
curl -s https://retina.example.com/metrics | head -20
# Expected: Prometheus-format text metrics beginning with # HELP retina_

# Check the readiness endpoint
curl -I https://retina.example.com/readyz
# Expected: HTTP/2 200

If Retina is deployed as a DaemonSet in Kubernetes, verify the agents are running on all nodes and their ports are accessible:

# Check DaemonSet status
kubectl get daemonset -n kube-system retina-agent

# Expected:
# NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE
# retina-agent    3         3         3       3            3

# Check pod status
kubectl get pods -n kube-system -l app=retina -o wide

# Test metrics from inside the cluster
kubectl run tmp-curl --image=curlimages/curl --rm -it --restart=Never \
  --namespace=kube-system -- curl -s http://retina-agent.kube-system.svc.cluster.local:10093/metrics | head -10

If Retina's metrics endpoint requires authentication, confirm credentials are set up correctly before configuring Vigilmon:

# Test with bearer token
curl -s -H "Authorization: Bearer $RETINA_TOKEN" \
  https://retina.example.com/metrics | head -5

# Verify the token is valid
kubectl get serviceaccount -n kube-system retina-agent
kubectl get secret -n kube-system | grep retina

Step 2: Set up HTTP monitoring in Vigilmon

Add an HTTP monitor for the Retina health endpoint:

Log in to vigilmon.online and click Add Monitor.
Set Monitor type to HTTP.
Enter the URL: https://retina.example.com/healthz
Set Check interval to 60 seconds and Expected status code to 200.
Click Save Monitor — Vigilmon will run the first check within a minute.

Add a monitor for the Retina metrics endpoint

The metrics endpoint is the core data path — a failure here means all network observability consumers are receiving stale data:

Click Add Monitor again.
Set Monitor type to HTTP.
Enter the URL: https://retina.example.com/metrics
Set Expected status code to 200 and Timeout to 15 seconds.
Under Response body contains, enter retina_ to confirm real Retina metrics are being returned.
Click Save Monitor.

Why external monitoring catches what internal checks miss

Retina is a network observability platform, which creates a fundamental blind spot: when Retina itself fails, the very tool your team relies on to diagnose network issues goes dark. Internal Kubernetes probes check whether the Retina pod is running and whether it passes its liveness check from inside the cluster — but they cannot detect whether the eBPF programs are actually loaded and collecting data, whether the metrics endpoint is reachable from external scrapers, or whether TLS certificates are about to expire. Vigilmon operates entirely outside your infrastructure, probing Retina from external network vantage points on a fixed interval. It is the only reliable way to know when your network observability stack is unavailable.

Step 3: Monitor Retina's TCP port

A TCP monitor confirms that the Retina metrics server is accepting connections at the network layer before HTTP processing begins. This catches scenarios where the metrics goroutine has panicked but the main agent process is still alive, or where the Service pointing to Retina pods has lost its endpoint backing.

In Vigilmon, click Add Monitor.
Set Monitor type to TCP.
Enter Host: retina.example.com and Port: 443.
Set Check interval to 60 seconds.
Click Save Monitor.

If your Retina deployment exposes metrics on the default port 10093 directly without a TLS proxy, add a second TCP monitor:

# Find the ports Retina is listening on
kubectl get pod -n kube-system -l app=retina -o jsonpath='{.items[0].spec.containers[0].ports}' | jq .

# Sample output:
# [
#   {"containerPort": 10093, "name": "metrics", "protocol": "TCP"},
#   {"containerPort": 10094, "name": "health",  "protocol": "TCP"}
# ]

Add separate TCP monitors for ports 10093 (metrics) and 10094 (health) to isolate which layer has failed when an alert fires.

Step 4: Configure alert channels

Email alerts

In Vigilmon, go to Alert Channels and click Add Channel.
Choose Email and enter the address that should receive notifications (for example, network-ops@example.com or an on-call distribution list).
Assign this channel to all Retina monitors created in Steps 2 and 3.
Click Save — Vigilmon will send a test email to confirm delivery.

Webhook alerts

For Slack, PagerDuty, or an internal incident management system, add a webhook channel:

In Alert Channels, click Add Channel and choose Webhook.
Paste your endpoint URL (a Slack incoming webhook, PagerDuty Events API v2 endpoint, or custom URL).
Vigilmon will POST the following JSON payload when a monitor transitions to down:

{
  "monitor_id": "mon_retina_healthz",
  "monitor_name": "Retina /healthz",
  "status": "down",
  "previous_status": "up",
  "checked_at": "2026-07-12T09:14:22Z",
  "response_time_ms": null,
  "status_code": null,
  "error": "Connection refused",
  "url": "https://retina.example.com/healthz"
}

Assign all Retina monitors to this channel and click Save.

Runbook: diagnostics to run when an alert fires

#!/bin/bash
# Retina alert runbook — run these in order when Vigilmon fires

echo "=== DaemonSet status ==="
kubectl get daemonset -n kube-system retina-agent

echo "=== Pod status ==="
kubectl get pods -n kube-system -l app=retina -o wide

echo "=== Recent events ==="
kubectl get events -n kube-system --sort-by='.lastTimestamp' | grep -i retina | tail -20

echo "=== Health endpoint response ==="
curl -sv https://retina.example.com/healthz 2>&1 | tail -20

echo "=== Metrics endpoint sample ==="
curl -s https://retina.example.com/metrics | grep retina_ | head -10

echo "=== Port connectivity ==="
nc -zv retina.example.com 443

echo "=== TLS certificate expiry ==="
echo | openssl s_client -connect retina.example.com:443 \
  -servername retina.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

echo "=== Agent logs (last 100 lines) ==="
kubectl logs -n kube-system -l app=retina --tail=100

echo "=== eBPF program status (on a specific node) ==="
NODE=$(kubectl get pods -n kube-system -l app=retina -o jsonpath='{.items[0].spec.nodeName}')
kubectl debug node/"$NODE" -it --image=ubuntu -- bpftool prog list 2>/dev/null | grep -i retina | head -20

Step 5: Create a public status page

A Vigilmon status page gives your network operations team and any teams that depend on network observability a single URL to check Retina health during incidents — no cluster access required.

In Vigilmon, navigate to Status Pages and click New Status Page.
Give it a name such as Retina Network Observability and choose a subdomain like retina-status.vigilmon.page.
Add all monitors created in this tutorial: the /healthz HTTP monitor, the /metrics HTTP monitor, and the TCP port monitor.
Optionally add a description explaining which teams depend on Retina for network visibility and incident investigation.
Click Publish — the page is immediately accessible and updates in real time.

Share this URL in your team's incident response runbook and link it from your network operations documentation so engineers know where to check when network observability data is missing or stale.

Putting it all together

| Monitor | Type | What it catches | |---|---|---| | https://retina.example.com/healthz | HTTP | Agent crash, eBPF load failure, process OOM kill, TLS expiry | | https://retina.example.com/metrics | HTTP | Metrics endpoint failure, goroutine panic, stale data detection | | retina.example.com:443 | TCP | Network-level connectivity loss, Service endpoint loss, load balancer failure |

# Quick-reference diagnostic one-liners when a Vigilmon alert fires

# 1. Are all Retina DaemonSet pods running?
kubectl get pods -n kube-system -l app=retina -o wide

# 2. Are there recent errors in the agent?
kubectl logs -n kube-system -l app=retina --tail=50

# 3. Can the health endpoint be reached?
curl -sf https://retina.example.com/healthz || echo "Health check FAILED"

# 4. Are metrics being returned?
curl -s https://retina.example.com/metrics | grep -c "retina_" || echo "No Retina metrics"

# 5. Is port 443 open?
nc -zv retina.example.com 443 && echo "Port open" || echo "Port CLOSED"

# 6. How long until the TLS cert expires?
echo | openssl s_client -connect retina.example.com:443 \
  -servername retina.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

What's next

SSL certificate monitoring — Vigilmon can alert you days before the TLS certificate on retina.example.com expires, giving you time to renew before Prometheus scrapers begin failing with TLS errors. Add an SSL monitor pointing at the same hostname.
Heartbeat monitoring for metrics pipeline continuity — Configure a cron job that queries the Retina metrics endpoint, verifies that key metrics like retina_drop_count have recent timestamps, and POSTs a heartbeat to a Vigilmon dead-man's-switch endpoint after each successful check. If the pipeline stops sending heartbeats, Vigilmon fires an alert that does not depend on the Retina stack being available.
Latency trend monitoring — Use Vigilmon's response time history to establish a latency baseline for the /healthz and /metrics endpoints. Sudden latency increases on the metrics endpoint often indicate eBPF map contention or metrics aggregation pipeline backpressure and give you time to investigate before data collection is interrupted.

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