GCP Memorystore Instance Idle
What does ZopNight detect here?
Memorystore instances showing zero connections (average and maximum below a small floor over 30 days) with no corroborating command throughput are flagged as idle, and the full monthly cost becomes the saving. CPU utilization is deliberately not used as a veto because the aggregator's unit scaling misreads that metric.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1245 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | memorystore_idle.go |
Where it applies
Connections as the sole authoritative signal
- MetricsAware (SetMultiMetrics): MemorystoreConnections read BY NAME off the nested UID→metricName view (Bug-1: memorystore harvests 8 metrics) over 30 days.
- PricingAware (SetPricing): per-resource monthly cost keyed by UID.
- No tag/Metadata fallback for idle detection: no GCP discoverer writes a connections signal, so the metric is the sole authoritative path and the rule abstains when it is absent.
Why CPU utilization is not a veto axis
concrete-or-abstain (cost-driven idle). Fires only when both MemorystoreConnections (required, avg and max below the small floor) and MemorystoreOpsPerSec (corroborating, when present) show zero measured activity over the window. Zero connections and no command throughput mean no application uses this cache, yet it bills hourly: CurrentCostUSD = SavingsUSD = cost, OptimizedCostUSD = 0. Abstains (returns nil) when pricing is unknown/zero, the required metric is absent, the ops/sec axis is present and active, or coverage is below 30d. Never a $0/advisory rec, never a fabricated fraction. (Was previously documented as a fixed estimate keyed on a connections tag.) MemorystoreCPU is deliberately not used as a corroborating veto axis. The aggregator maps redis.googleapis.com/stats/cpu_utilization with scaleFactor:100 under a 0.0-1.0 -> percent assumption, but GCP documents that metric as CPU-seconds consumed per minute: an unbounded delta, not a ratio. Gating on it at a small “percent” floor would trip on routine background housekeeping (serverCron/replication) that any non-fully-quiesced Redis instance performs, vetoing genuinely idle instances almost unconditionally. Correcting the unit requires an aggregator-side (producer) change that is out of scope for this rule; until then RC-1245 relies solely on connections + ops/sec, both of which the aggregator scales correctly.
Checking nothing still connects
- Verify no applications are configured to connect to this instance
Connections required, ops per second corroborating
MemorystoreConnections (required) + MemorystoreOpsPerSec (30d, multi-axis gate: connections required, ops/sec corroborating veto)