CLOUDM0N
Repository intelligence

kubernetes-csi/external-health-monitor

GitHub

A Container Storage Interface (CSI) sidecar container that watches Kubernetes volumes, periodically queries their health via the driver's controller service, and writes any adverse conditions to the PersistentVolumeClaim status.

CLOUDM0N decision
NICHE
Trust PASS · 100/100
Good fit if

Kubernetes cluster administrators looking to automate the detection and reporting of storage volume health issues within the cluster.

Watch out for

Exits immediately at startup if the underlying CSI driver does not advertise the required GET_VOLUME_HEALTH capability.

Practical intelligence

What matters before you adopt it

Problem it solves

The lack of automated, controller-side reporting of physical storage volume health conditions and faults directly to the Kubernetes API.

Best for
Kubernetes cluster administrators looking to automate the detection and reporting of storage volume health issues within the cluster.
Storage engineering teams developing or managing CSI drivers that support volume health checks.
Main trade-offs
Exits immediately at startup if the underlying CSI driver does not advertise the required GET_VOLUME_HEALTH capability.
Relies strictly on the CSIVolumeHealth feature gate being enabled on the kube-apiserver; otherwise, status writes are silently dropped by the API server.
Why it stands out
Provides native integration with Kubernetes PVC statuses to record standard Inaccessible, DataLoss, and Degraded conditions.
Offers two distinct operational modes: individual volume polling and efficient, bulk paginated health checks.
Features a robust, configurable leader-election mechanism to support highly available, multi-replica controller deployments.
Trust & CVEs

Security evidence without the noise

Trust remains a decision signal; CVEs and scanner evidence explain what is driving the risk.

Security findings
—
Scanner unavailable
Critical
—
High
—
Medium
—
Low
—
View trust evidence & security findings▼
Why this score
No trust rationale was stored for this scan.
CLOUDM0N findings
Architecture from code10 modules · 0 edges▼
Structural evidence

Modules and dependency edges extracted from repository code. This is code evidence, not README inference.

Code files
2
Modules
10
Dependency edges
0
Core modules
release-tools
2 files
Dependency flow
No dependency edges were extracted.
Detected languages
Go · Shell · Python
Detected frameworks
—
Architecture evidence details
flowchart TD
    %% repo — high-level architecture (DRAFT, refine me)
    n0["release-tools · 2 files"]
Evidence, security & integrations▼
Integrations
Kubernetes API ServerCSI (Container Storage Interface) SpecificationPrometheusklog
Security notes
• Utilizes the default service account token provided by Kubernetes when running in-cluster, with an optional fallback to an external kubeconfig file for local debugging.
Still unknown
• The README does not provide the actual shell commands or parameters to execute under the 'Build && Push Image' section header.
• It lacks pre-written YAML manifest files or helm charts for easy production installation.
• It does not outline memory, CPU, or latency scaling performance under large-scale clusters with high PVC counts.
Adoption guidance▼
Adopt if
+ Your storage provider's CSI driver supports the GET_VOLUME_HEALTH controller capability.
+ You want a standardized, KEP-1432-compliant way to surface physical storage health issues directly on your PVCs.
Avoid if
– Your CSI driver does not support GET_VOLUME_HEALTH, or advertises LIST_VOLUME_HEALTH without GET_VOLUME_HEALTH.
– You cannot enable the CSIVolumeHealth feature gate on your kube-apiserver.
How it works & getting started▼
How it works
1.The sidecar container is deployed within the CSI controller driver pod inside the cluster.
2.It establishes communication with the CSI driver via the local socket path.
3.It queries the CSI driver's capabilities to verify health monitor compatibility.
4.It periodically retrieves the health status of bound volumes using bulk lists or individual queries.
5.It updates the bound PVC's status health conditions with authoritative reports from the driver.
Getting started
→ Build, tag, and push the controller container image from the project's root directory.
→ Deploy the sidecar container alongside your CSI controller driver.
→ Confirm the pods are running successfully by executing: kubectl get pods
→ Inspect the monitor logs by executing: kubectl logs <leader-pod-name> -c csi-external-health-monitor-controller
Agent handoff
Use with any agent
JSON API
Alternatives

Nearby repositories worth comparing before adoption.

Compare top options →
helm-charts
aws-observability/helm-charts
58
Fit

The AWS Observability Helm Charts repository contains Helm charts to provide easy mechanisms to setup the CloudWatch Agent and other collection agents to collect telemetry data such as metrics, logs and traces to send to AWS monitoring services.

Trust PASS · 100
Compare →
spug
openspug/spug
63
Fit

Spug is a lightweight agent-free automatic operation and maintenance platform designed for small and medium-sized enterprises. It integrates host management, host batch execution, host online terminal, file management, application release and deployment, pipelines, online task planning, configuration center, monitoring, alarm and so on.

Trust REVIEW · 65
Compare →
signoz
SigNoz/signoz
62
Fit

SigNoz is an open-source, OpenTelemetry-native observability platform for your team and their AI agents. Get logs, metrics, and traces in one tool with features like APM, distributed tracing, log management, infra monitoring, etc. Combined with SigNoz MCP and a native AI teammate (in SigNoz Cloud) it helps you build more resilient apps.

Trust REVIEW · 90
Compare →