tutorial

Monitoring Piraeus with Vigilmon: LINSTOR Controller Health, Storage Node Availability, DRBD Resource Status & Backup Heartbeats

How to monitor Piraeus (LINSTOR/DRBD-based HA storage for Kubernetes) with Vigilmon — LINSTOR controller health checks, storage node availability, DRBD resource status, SSL certificate monitoring, and backup completion heartbeats.

Piraeus is a Kubernetes operator that delivers highly available block storage using LINSTOR and DRBD — providing synchronous replication across cluster nodes for stateful workloads that require persistent, fault-tolerant storage. As the storage substrate for databases, message queues, and any pod needing durable volumes, a Piraeus failure means data is inaccessible or unprotected. A degraded LINSTOR controller, an unreachable storage satellite, or a DRBD split-brain leaves your workloads without storage long before an alert is raised. Vigilmon gives you external visibility into the LINSTOR API health, storage node availability, DRBD resource state, SSL certificates, and backup completion heartbeats so you catch failures before they reach your applications.

What You'll Build

  • A monitor on the LINSTOR controller REST API
  • A storage node availability check via the LINSTOR API
  • A DRBD resource health check via keyword matching
  • SSL certificate monitoring for the LINSTOR API endpoint
  • A heartbeat monitor confirming scheduled backup jobs complete on time

Prerequisites

  • A running Piraeus installation in Kubernetes with the LINSTOR controller exposed at a URL
  • LINSTOR REST API accessible over HTTPS (via an Ingress or LoadBalancer)
  • A free account at vigilmon.online

Step 1: Verify the LINSTOR Controller Health Endpoint

The LINSTOR controller exposes a REST API with a health endpoint confirming the controller is operational:

curl https://linstor.example.com/health

A healthy LINSTOR controller returns:

{"status":"ONLINE"}

This confirms the LINSTOR controller pod is alive and its internal API server is responding. Node and resource health are checked in subsequent steps.

Step 2: Create a Vigilmon HTTP Monitor for the LINSTOR API

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://linstor.example.com/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ONLINE (the status field value).
  7. Label: Piraeus LINSTOR Controller Health.
  8. Click Save.

Set alerts to trigger after 1 consecutive failure — a LINSTOR controller outage blocks all volume provisioning, snapshot creation, and replica management for the entire cluster.

Step 3: Monitor the LINSTOR API Root

Beyond the /health endpoint, the LINSTOR REST API root at /v1 confirms the API server is serving requests and not just passing a shallow health probe. A broken API server can return a positive health check while API calls fail:

curl https://linstor.example.com/v1
  1. Add Monitor → HTTP.
  2. URL: https://linstor.example.com/v1.
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Label: Piraeus LINSTOR API Root.
  6. Click Save.

Step 4: Monitor Storage Node (Satellite) Availability

Piraeus runs LINSTOR satellites on each storage node. When a satellite disconnects from the controller, that node's storage resources become unavailable and replicas degrade. The LINSTOR API exposes node status at /v1/nodes:

curl https://linstor.example.com/v1/nodes

A healthy response contains an array of nodes with "connection_status": "ONLINE" for each satellite:

[
  {"name": "node-1", "connection_status": "ONLINE"},
  {"name": "node-2", "connection_status": "ONLINE"}
]

Add a monitor using keyword matching to confirm at least one satellite is connected:

  1. Add Monitor → HTTP.
  2. URL: https://linstor.example.com/v1/nodes.
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: ONLINE.
  6. HTTP Headers: Authorization: Basic your-base64-credentials (if authentication is required).
  7. Label: Piraeus Storage Nodes.
  8. Click Save.

Authentication: LINSTOR supports HTTP Basic authentication. If your API requires credentials, add the Authorization header with base64-encoded user:password in the monitor's header configuration.

Keyword limitation: The ONLINE keyword confirms at least one satellite is healthy but does not detect partial failures. For quorum-level monitoring, pair Vigilmon with LINSTOR's Prometheus metrics or Kubernetes events.

Step 5: Monitor DRBD Resource Status

DRBD resources back each Piraeus volume with synchronous replication. When a resource enters StandAlone, Diskless, or SyncSource/SyncTarget states unexpectedly, data integrity is at risk. The LINSTOR API exposes resource state at /v1/resource-definitions:

curl https://linstor.example.com/v1/resource-definitions

A healthy response shows resource definitions with their associated resource groups. For operational DRBD state, query /v1/resources:

curl https://linstor.example.com/v1/resources

Add a monitor to confirm resources are present:

  1. Add Monitor → HTTP.
  2. URL: https://linstor.example.com/v1/resources.
  3. Check interval: 5 minutes.
  4. Expected status: 200.
  5. Keyword: node_name (present in the response when resources are allocated).
  6. Label: Piraeus DRBD Resources.
  7. Click Save.

Note: If no resources are provisioned yet, the /v1/resources response returns an empty array. In that case, use the node satellite check from Step 4 as your primary health signal and add resource monitoring once workloads are running.

Step 6: Set Up Backup Completion Heartbeat Monitoring

Piraeus volumes can be snapshotted and backed up via LINSTOR's snapshot feature or external tooling such as Velero. A backup job that silently fails leaves your volumes unprotected. Use Vigilmon heartbeat monitoring to confirm backups complete on schedule:

Step 6a — Create a Heartbeat monitor in Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Name: Piraeus daily backup.
  3. Expected interval: 24 hours (or match your backup schedule).
  4. Grace period: 2 hours.
  5. Copy the generated ping URL (e.g., https://vigilmon.online/ping/abc123).

Step 6b — Add a ping step to your backup CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: piraeus-backup-heartbeat
  namespace: piraeus-system
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup-and-ping
              image: curlimages/curl:latest
              command:
                - sh
                - -c
                - |
                  # Run your LINSTOR snapshot backup here, then ping on success
                  curl -fsS -m 10 https://vigilmon.online/ping/abc123
          restartPolicy: OnFailure

If the backup job fails or the CronJob is deleted, Vigilmon fires an alert after the grace period expires, giving you a safety net against silent backup failures.

Step 7: Monitor SSL Certificates

The LINSTOR REST API is consumed by the Piraeus operator, kubectl-linstor plugin, and any automation scripts. An expired certificate causes TLS errors across all API consumers, breaking volume provisioning for the entire cluster:

  1. Add Monitor → SSL Certificate.
  2. Domain: linstor.example.com (your LINSTOR controller domain).
  3. Alert when expiry is within: 30 days.
  4. Alert again at: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Step 8: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | LINSTOR health | Non-200 or ONLINE missing | Check controller pod; kubectl get pods -n piraeus-system | | API root | Non-200 | Controller restart or ingress issue | | Storage nodes | ONLINE absent | Satellite disconnected; check node network and satellite pod | | DRBD resources | node_name absent | No resources provisioned or controller unreachable | | Backup heartbeat | No ping within window | Backup failed; verify snapshot job and backup target | | SSL certificate | < 30 days | Renew; verify cert-manager TLS config |

Common Piraeus Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | LINSTOR controller pod crash | /health unreachable; alert within 60 s | | Storage satellite disconnects | Nodes API loses ONLINE state; replica redundancy drops | | DRBD split-brain on node failure | Resources API reflects missing allocations | | Volume provisioning stalls | Controller API down; new PVCs stay Pending | | Backup job fails silently | Heartbeat monitor alerts after grace period | | SSL certificate expires | SSL monitor alerts at 30-day threshold | | Ingress controller misconfigured | API root monitor fires; controller may still be reachable internally | | All satellites evicted | Node and resource monitors both fire; cluster-level storage loss |

Piraeus's DRBD-backed replication model means storage failures cascade quickly — a disconnected satellite loses replica redundancy, a split-brain leaves volumes in an inconsistent state, and a LINSTOR controller outage blocks all new volume provisioning. Vigilmon's layered monitoring of the LINSTOR controller health, satellite availability, resource status, backup heartbeats, and SSL certificates gives you external visibility across every layer of Piraeus's HA storage stack, so you catch failures before they reach your stateful workloads.

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

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