How to Monitor CSI Driver SMB with Vigilmon (HTTP + TCP + Alerts)

CSI Driver SMB lets Kubernetes workloads mount SMB/CIFS file shares from Windows Server, Azure Files, and Samba servers as persistent volumes. The controller plugin handles PV lifecycle while the node plugin DaemonSet mounts shares on every node — but when the SMB backend becomes unreachable or the node plugin fails, pods silently lose access to their volumes with no Kubernetes-native alert.

In this tutorial you'll set up comprehensive uptime monitoring for CSI Driver SMB — and the SMB file servers behind it — using Vigilmon — free tier, no credit card required.

Why CSI Driver SMB needs external monitoring

CSI Driver SMB is distributed across controller and node roles. Kubernetes pod health checks only tell you a container is running, not that SMB mounts are functional:

• SMB server goes offline — CSI node plugin pods stay Running but all SMB mounts stall; pods attempting to mount or remount volumes block indefinitely waiting for the SMB handshake
• Node plugin pod evicted — a node under memory pressure evicts the CSI DaemonSet pod; pods on that node can no longer mount new SMB shares even though the backend is healthy
• SMB authentication failure — a password rotation or AD domain join issue breaks NTLM/Kerberos auth on the server; the CSI driver returns access denied but reports itself healthy
• Network policy change blocks port 445 — a firewall rule update silently blocks SMB traffic; the CSI controller pod is healthy but every mount request fails at the OS level
• Controller crash during provision — the controller pod restarts mid-provision; the PVC stays Pending and the PV is never created, with no event surfaced to the namespace owner

External monitoring from multiple geographic regions catches failures spanning the SMB protocol path and CSI driver layers simultaneously.

What you'll need

• A Kubernetes cluster with CSI Driver SMB installed (via Helm or manifest)
• One or more SMB file servers providing shares to the cluster
• A free Vigilmon account (sign up takes 30 seconds)

Step 1: Expose CSI Driver SMB health endpoints

Expose the controller plugin health endpoint

The CSI Driver SMB controller plugin exposes a liveness probe on port 29642. Expose it via NodePort:

# csi-smb-controller-health-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: csi-smb-controller-health
  namespace: kube-system
spec:
  type: NodePort
  selector:
    app: csi-smb-controller
  ports:
    - name: healthz
      port: 29642
      targetPort: 29642
      nodePort: 30642
      protocol: TCP

Apply it:

kubectl apply -f csi-smb-controller-health-svc.yaml

Verify the health endpoint:

curl http://<node-ip>:30642/healthz
# ok

Expose the node plugin health endpoint

The node plugin runs on every node as a DaemonSet. Expose port 29643 (node liveness probe) via NodePort:

# csi-smb-node-health-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: csi-smb-node-health
  namespace: kube-system
spec:
  type: NodePort
  selector:
    app: csi-smb-node
  ports:
    - name: healthz
      port: 29643
      targetPort: 29643
      nodePort: 30643
      protocol: TCP

kubectl apply -f csi-smb-node-health-svc.yaml
curl http://<node-ip>:30643/healthz
# ok

Confirm both DaemonSet pods are running across all nodes:

kubectl get daemonset -n kube-system csi-smb-node
# NAME           DESIRED   CURRENT   READY   ...
# csi-smb-node   3         3         3       ...

Step 2: Set up HTTP monitoring in Vigilmon

With health endpoints exposed, add CSI Driver SMB to Vigilmon:

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to http://<node-ip>:30642/healthz
4. Set the check interval to 1 minute
5. Under Expected response, set:
   • Status code: 200
   • Response body contains: ok
6. Save the monitor
7. Repeat for http://<node-ip>:30643/healthz (node plugin)

The multi-region consensus advantage

Vigilmon probes your endpoints from multiple geographic regions simultaneously. Because CSI Driver SMB health depends on both the Kubernetes control plane and external SMB servers, a single probe failure could reflect a transient network path issue. Vigilmon's multi-region consensus requires multiple independent probes to agree before triggering an alert — accurate detection without false positives.

Step 3: Monitor your TCP layer

TCP monitoring catches SMB server reachability failures before they manifest as HTTP errors or mount timeouts.

In Vigilmon:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your node IP and port 30642 (controller health)
4. Save the monitor
5. Add a TCP monitor for port 30643 (node plugin health)
6. Add a TCP monitor for <smb-server-ip> on port 445 (SMB protocol port)

The SMB server TCP monitor on port 445 is critical — it's your earliest warning that the file server backend is unreachable, before any CSI pod logs an error.

# Confirm SMB server TCP port from cluster
nc -zv <smb-server-ip> 445
# Connection to <smb-server-ip> 445 port [tcp/microsoft-ds] succeeded!

# If using older NetBIOS-based SMB:
nc -zv <smb-server-ip> 139

Step 4: Configure alert channels

A failed CSI Driver SMB node plugin blocks all new SMB mounts on that node. An unreachable SMB server stalls every mounted share cluster-wide. You need to know immediately.

Email alerts

1. In Vigilmon, go to Alert Channels → Add Channel → Email
2. Enter your on-call or storage-team email address
3. Assign the channel to your CSI SMB controller, node, and SMB server monitors

Webhook alerts (Slack, PagerDuty, etc.)

1. Go to Alert Channels → Add Channel → Webhook
2. Enter your webhook URL
3. Assign the channel to your monitors

Example payload Vigilmon sends when a monitor goes down:

{
  "monitor_name": "csi-smb-controller /healthz",
  "status": "down",
  "url": "http://203.0.113.50:30642/healthz",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 60
}

When you receive a CSI SMB alert, correlate it with the cluster:

# Check CSI controller pod status
kubectl get pods -n kube-system -l app=csi-smb-controller

# Check CSI node plugin DaemonSet — look for not-Ready nodes
kubectl get pods -n kube-system -l app=csi-smb-node -o wide

# Check for pending PVCs
kubectl get pvc -A | grep -E 'Pending|Terminating'

# Check CSI controller logs for mount or auth errors
kubectl logs -n kube-system deploy/csi-smb-controller -c smb --tail=50

# Test SMB reachability from a node
kubectl run smb-debug --image=busybox --rm -it --restart=Never -- \
  sh -c "nc -zv <smb-server-ip> 445"

Step 5: Create a public status page

SMB-backed shares are often used by multiple teams. A public status page lets everyone check storage health without needing kubectl access.

1. In Vigilmon, go to Status Pages → New Status Page
2. Give it a name: "Storage Infrastructure — CSI Driver SMB"
3. Add your monitors: controller health, node plugin health, SMB server TCP
4. Group them: CSI Controller, CSI Node Plugin, SMB Servers
5. Publish the page

Share the status page URL in your runbook and with teams that own SMB-backed workloads.

Putting it all together

Here's a summary of the monitors to create for a CSI Driver SMB deployment:

| Monitor | Type | What it catches | |---------|------|-----------------| | http://<node-ip>:30642/healthz | HTTP | Controller plugin health, crash loops, OOMKill | | http://<node-ip>:30643/healthz | HTTP | Node plugin health, DaemonSet pod evictions | | <node-ip>:30642 | TCP | Controller port reachability | | <node-ip>:30643 | TCP | Node plugin port reachability | | <smb-server-ip>:445 | TCP | SMB server reachability — catches mount failures cluster-wide | | <smb-server-ip>:139 | TCP | NetBIOS SMB (legacy environments) |

Verify the full CSI SMB driver state in your cluster:

# List all CSI SMB pods
kubectl get pods -n kube-system -l 'app in (csi-smb-controller,csi-smb-node)' -o wide

# List PVs backed by CSI SMB
kubectl get pv -o custom-columns='NAME:.metadata.name,DRIVER:.spec.csi.driver,SHARE:.spec.csi.volumeAttributes.source'

# Check the CSI driver registration
kubectl get csidrivers smb.csi.k8s.io

# View attached volumes and their nodes
kubectl get volumeattachments -o custom-columns='NAME:.metadata.name,ATTACHER:.spec.attacher,NODE:.spec.nodeName,ATTACHED:.status.attached'

What's next

• Multiple SMB server coverage — if different storage classes point to different SMB servers, add a TCP monitor for each server's port 445
• Azure Files endpoint monitoring — if using Azure Files as the SMB backend, add HTTP monitors for the Azure Files REST health endpoint
• Heartbeat monitoring — if you run batch jobs that write to SMB-backed PVCs, Vigilmon's heartbeat monitors alert you when a job stops reporting in

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