# GKE Cluster Monitoring Disabled

> 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.

Source: https://zop.dev/integrations/gcp/recommendations/gke-cluster-monitoring-disabled
Updated: 2026-08-19

---

## 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

```bash
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.