Monitoring Meshery with Vigilmon: Management Plane Availability, Service Mesh Adapter Health, Kubernetes Connectivity & SSL Certificate Alerts

Meshery is the cloud native management platform that provides a single control plane for deploying, managing, and observing service meshes like Istio, Linkerd, Consul, and NGINX Service Mesh across Kubernetes clusters. When the Meshery server goes down, operators lose visibility into mesh configuration drift, cannot deploy mesh changes, and performance analysis data stops accumulating. When a Meshery adapter for a specific mesh becomes unavailable, that mesh falls outside the management plane's view while appearing healthy in cluster state. Vigilmon gives you external visibility into Meshery's server health, each deployed mesh adapter, the Kubernetes API connectivity that Meshery depends on, and the SSL certificates protecting the management UI so you always know the true health of your management plane.

What You'll Build

• An HTTP monitor on Meshery's server health endpoint to detect process failures
• HTTP monitors on each deployed Meshery mesh adapter (Istio, Linkerd, Consul, etc.)
• A TCP check to verify the Meshery gRPC port is accepting adapter connections
• A monitor for Meshery's Kubernetes API server connectivity
• SSL certificate monitoring for the Meshery UI domain
• An alert runbook mapping Vigilmon findings to specific mesheryctl and kubectl remediation commands

Prerequisites

• Meshery v0.6+ deployed via mesheryctl or Helm in the meshery namespace
• At least one service mesh adapter deployed (Istio, Linkerd, Consul, or similar)
• kubectl access to the cluster running Meshery
• mesheryctl CLI installed and configured
• A free account at vigilmon.online

Step 1: Understand Meshery's Observability Surface

Meshery exposes an HTTP API server and adapter gRPC connections. Before configuring external monitoring, inspect what is available:

# Check Meshery pod status in the meshery namespace
kubectl get pods -n meshery

# View live Meshery server logs
kubectl logs -n meshery deployment/meshery --tail=50 -f

# Port-forward the Meshery UI and API
kubectl port-forward -n meshery svc/meshery 9081:9081

# Test the Meshery health endpoint
curl http://localhost:9081/api/system/health
# Expected: {"server_version":"...","database_version":"..."}

# List connected adapters via Meshery CLI
mesheryctl system status

# Check which adapters are registered
curl http://localhost:9081/api/system/adapters

The key signals are:

• /api/system/health: Returns server version and database version when Meshery is healthy. Fails or returns errors when the database is unavailable.
• Adapter status: Each adapter runs as a separate pod. An adapter pod crash removes that mesh from Meshery's management view while the Meshery server itself stays healthy.
• Kubernetes connectivity: Meshery communicates with the Kubernetes API server to apply mesh configurations. Loss of this connectivity causes operations to queue or fail silently.
• Database availability: Meshery uses an embedded SQLite database by default; external PostgreSQL in production. Database failures corrupt performance test results and design state.

Step 2: Expose Meshery for External Monitoring

The Meshery server listens on port 9081. Expose it via an Ingress for external health monitoring:

# meshery-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meshery
  namespace: meshery
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
spec:
  rules:
  - host: meshery.example.com
    http:
      paths:
      - path: /api/system/health
        pathType: Exact
        backend:
          service:
            name: meshery
            port:
              number: 9081
      - path: /
        pathType: Prefix
        backend:
          service:
            name: meshery
            port:
              number: 9081
  tls:
  - hosts:
    - meshery.example.com
    secretName: meshery-tls

kubectl apply -f meshery-ingress.yaml

# Verify external access
curl https://meshery.example.com/api/system/health

Step 3: Create a Vigilmon HTTP Monitor for Meshery Server Health

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://meshery.example.com/api/system/health.
3. Check interval: 2 minutes.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: server_version (present in the health response JSON).
7. Label: meshery server health.
8. Click Save.

This monitor catches:

• Meshery server process crashes after plugin installation or configuration changes
• Database lock contention causing the server to become unresponsive
• Memory pressure during large-scale performance test result ingestion
• Pod evictions during cluster resource pressure events
• Failed Meshery upgrades that leave the new version in crash-loop

Alert sensitivity: Set to trigger after 2 consecutive failures to suppress transient restarts during mesheryctl system restart operations.

Step 4: Monitor Meshery Adapter Availability

Each Meshery service mesh adapter runs as a separate pod and communicates with the Meshery server over gRPC. When an adapter pod crashes, Meshery loses visibility into that mesh's configuration, performance, and conformance state:

# List all adapter pods
kubectl get pods -n meshery -l component=adapter

# Check a specific adapter (e.g., Istio adapter)
kubectl get pods -n meshery -l app=meshery-istio

# View adapter logs
kubectl logs -n meshery deployment/meshery-istio --tail=30

# Check adapter health endpoints (each adapter exposes one)
kubectl port-forward -n meshery svc/meshery-istio 10000:10000
curl http://localhost:10000/api/health

For each deployed adapter, expose it via a NodePort or Ingress path and add a Vigilmon monitor:

# Example: expose Istio adapter health
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meshery-istio-adapter
  namespace: meshery
spec:
  rules:
  - host: meshery.example.com
    http:
      paths:
      - path: /adapters/istio/health
        pathType: Exact
        backend:
          service:
            name: meshery-istio
            port:
              number: 10000

In Vigilmon, add one monitor per adapter:

1. Add Monitor → HTTP.
2. URL: https://meshery.example.com/adapters/istio/health.
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Label: meshery istio adapter.
6. Click Save.

Repeat for each adapter: Linkerd (port 10001), Consul (port 10002), NGINX Service Mesh (port 10010), Kuma (port 10007).

Step 5: Monitor the Meshery gRPC Adapter Port

Meshery server communicates with adapters over gRPC on port 9081. If the gRPC listener fails, all adapter communications break even though the HTTP health endpoint on the same port may still respond:

# Verify gRPC port is reachable
grpc_health_probe -addr=meshery.example.com:9081

# Alternative: TCP check
nc -zv meshery.example.com 9081

In Vigilmon:

1. Add Monitor → TCP.
2. Host: meshery.example.com.
3. Port: 9081.
4. Check interval: 2 minutes.
5. Label: meshery grpc port.
6. Click Save.

Why the TCP check matters in addition to HTTP: The Meshery server binds HTTP and gRPC on the same port using content-type routing. A crash in the gRPC handler can stall adapter connections while still serving HTTP health checks. The TCP check ensures the port is accepting connections at all; the HTTP check validates the HTTP layer specifically.

Step 6: Monitor Meshery Operator and MeshSync

Meshery Operator watches Kubernetes events and runs MeshSync to maintain a live inventory of mesh resources. If the Operator pod crashes, Meshery's cluster state view goes stale silently:

# Check Meshery Operator status
kubectl get pods -n meshery -l app=meshery-operator

# View Operator logs
kubectl logs -n meshery deployment/meshery-operator --tail=30

# Check MeshSync health
kubectl get pods -n meshery -l app=meshsync
kubectl logs -n meshery deployment/meshsync --tail=30

Add monitors for the Operator and MeshSync health endpoints using the same Ingress pattern as the adapters. Alternatively, set up an alerting rule in Vigilmon watching the Meshery server API for stale inventory timestamps:

# Check when Meshery last received a MeshSync event
curl https://meshery.example.com/api/system/sync

Step 7: Monitor SSL Certificates

Meshery's management UI and API are the single control point for your service mesh infrastructure. A certificate expiry on the Meshery domain locks out operators from managing, observing, or changing any mesh configuration:

# Check the Meshery UI certificate
openssl s_client -connect meshery.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Check any adapter-specific certificates
openssl s_client -connect adapters.meshery.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

In Vigilmon:

1. Add Monitor → SSL Certificate.
2. Domain: meshery.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

Step 8: Configure Alerting and Runbook

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Immediate Action | |---|---|---| | Meshery server health | Non-200 or server_version keyword missing | kubectl get pods -n meshery -l app=meshery → check restarts; kubectl logs -n meshery deployment/meshery --tail=30 | | Istio adapter | Non-200 | kubectl get pods -n meshery -l app=meshery-istio → check crash; verify Istio control plane is reachable | | Linkerd adapter | Non-200 | kubectl get pods -n meshery -l app=meshery-linkerd → check crash; verify Linkerd CRDs are installed | | Meshery gRPC TCP | Connection refused | Restart Meshery server: mesheryctl system restart; check port conflicts | | MeshSync | Pod not running | kubectl describe pod -n meshery -l app=meshsync; check RBAC permissions for cluster-wide list/watch | | SSL certificate | < 30 days to expiry | kubectl get certificates -n meshery; trigger cert-manager renewal manually |

Escalation policy: Alert the platform team on Meshery server failures via an out-of-band channel. If Meshery is down, operators can't access the management UI to acknowledge the alert, so the alert must reach them through a separate path (Vigilmon → email/SMS → on-call).

Common Meshery Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Meshery server OOM killed during large perf test ingestion | Server health endpoint goes down; alert within 2 min | | Istio adapter pod evicted during node pressure | Istio adapter monitor catches failure; Meshery server stays healthy | | MeshSync loses Kubernetes API server connectivity | Server health stays green; mesh inventory goes stale — monitor /api/system/sync for stale timestamps | | cert-manager fails to renew Meshery TLS certificate | SSL monitor catches 30 days before browsers block UI access | | Meshery database (SQLite/Postgres) becomes corrupted | Server health endpoint fails; TCP check on PostgreSQL confirms database is the root cause | | Meshery Operator RBAC revoked after cluster policy change | Operator pod stays running; mesh inventory stops updating; MeshSync health check catches it | | Helm upgrade to new Meshery version fails mid-rollout | Server health endpoint goes down during rollout; alert within 2 min | | Adapter gRPC connection pool exhausted | HTTP health stays green; adapter monitors detect 502 on adapter health paths |

Meshery provides unified visibility and control over service mesh infrastructure that spans multiple clusters and mesh implementations — but that control plane itself needs to be monitored externally. Vigilmon provides the independent external eye that checks whether Meshery's server, its mesh adapters, and its Kubernetes operator are all functioning correctly, without relying on Meshery itself to report its own health. When any component of the management plane fails, you get notified with enough context to identify whether the problem is Meshery, a specific adapter, or an upstream dependency.

Start monitoring Meshery in under 5 minutes — register free at vigilmon.online.