GKE clusters not sending metrics to Cloud Monitoring
What does ZopNight detect here?
ZopNight rule RC-1220 flags GKE clusters whose discoverer label reads monitoring=false, meaning node, pod, and control-plane metrics never reach Cloud Monitoring. The producer derives the label from monitoringConfig struct presence, so modern clusters can under-report. The rule fails closed on what it is given, firing only on an explicit false.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1220 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | gke_monitoring.go |
Where it applies
What a false monitoring label proves, and what it cannot
Rule RC-1220 evaluates one signal: the monitoring label the discoverer’s producer writes onto the cluster. Only an explicit false fires; an absent or malformed value returns nothing, so a cluster the producer never characterised is never flagged. Read the caveat carefully, though: the producer derives that label from the presence of the monitoringConfig structure rather than from componentConfig.enableComponents, so on modern clusters (where Managed Service for Prometheus ships default-on), a cluster with monitoring genuinely disabled can still look configured and escape the rule. In other words, a firing is trustworthy evidence of a dark cluster, but a silent rule is not proof of a monitored one. The producer-side derivation is the acknowledged defect; the rule’s contribution is refusing to guess.
Running Kubernetes without instruments
A GKE cluster that exports no metrics still schedules pods, but every operational question becomes folklore. Is the node pool near memory pressure? Are pods restarting in a crash loop? Did last night’s deploy double p99 latency at the infrastructure layer? Cloud Monitoring is also the substrate for alerting policies and for autoscaling signals beyond bare CPU, none of which exist for a dark cluster. ZopNight’s own utilisation-based recommendations read monitoring.timeSeries.list under roles/monitoring.viewer; a cluster with monitoring off is invisible to that entire class of analysis, so the finding compounds: no metrics today, and no idle or rightsizing insight tomorrow.
Confirm what the cluster actually exports
gcloud container clusters describe my-cluster --location us-central1 \ --format='value(monitoringConfig.componentConfig.enableComponents)'An empty component list is the disabled state this rule is hunting, whatever the legacy monitoringService field claims.
Re-enabling without a rebuild
Monitoring is an in-place update: gcloud container clusters update my-cluster --monitoring=SYSTEM restores system metrics, and workload scraping can come from Managed Prometheus on top. Enable SYSTEM even on cost-sensitive clusters; it is the floor that keeps node and control-plane health observable. Then wire at least one alerting policy to the restored metrics, because a cluster that was dark once has demonstrated that nobody was looking.