fix(metrics): grow VM to 40Gi, cut retention to 14d, retain the PVC #21
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/vm-storage-and-retention"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
VictoriaMetrics filled its 20Gi disk and went READ-ONLY, so the cluster ingested NO metrics for ~34h (vmagent got 503
the storage is in read-only modeand retried the same blocks 2040 times). Every Grafana panel showed No data.Nothing stored was lost. Verified by querying past timestamps: 36h/48h/72h/168h ago all return data; 6h/24h ago return none. It is a GAP in ingestion, not a deletion.
Disk was 19.9G of 19.9G with 4.9M free. The
2026_07partition alone was 12.0G (5.7G data + 6.3G index).Changes
allowVolumeExpansion=trueand every pool has 138-178 GiB free. Already expanded online: the volume went to 40 GiB and stayed Online at 5 replicas, no rebuild triggered.2026_07was pinned until Aug 30 and the disk could never drain.Deleteputs an ownerReference withblockOwnerDeletion: trueon the PVC - and changingvolumeClaimTemplatesREQUIRES deleting the StatefulSet, which would have garbage-collected the PVC and every metric in it.Retainmakes that edit safe. (PV was already Retain.)Known and NOT fixed here
The index is larger than the samples (10.1G vs 9.3G). That is a cardinality problem - likely per-pod labels on short-lived Argo workflow pods. Worth a separate look.