goldilocks dash vpa

Author: mitchross

docs/cnpg-disaster-recovery.md

@@ -51,6 +51,15 @@ s3://postgres-backups/cnpg/immich/
 
 **Each recovery bumps the version**: `-v2` → `-v3` → `-v4`, etc.
 
+### Restore Source vs Backup Target (Critical)
+
+During recovery, treat these as two different values:
+
+- `externalClusters[].barmanObjectStore.serverName` = **restore source** (existing lineage, e.g. `immich-database-v2`)
+- `backup.barmanObjectStore.serverName` = **new backup target** (next lineage, e.g. `immich-database-v3`)
+
+After recovery succeeds, keep backups on the new lineage (`v3`). Do **not** switch backup target back to `v2`.
+
 ## Recovery Procedure
 
 ### Prerequisites
@@ -130,7 +139,7 @@ In `cluster.yaml`:
 - Uncomment `initdb` bootstrap
 - Comment out `recovery` bootstrap + `externalClusters`
 - Keep the new `serverName` in the backup section (e.g. `immich-database-v3`)
-- Update the commented recovery `externalClusters.serverName` to match the new backup serverName
+- Update the commented recovery `externalClusters.serverName` for next time (e.g. `immich-database-v3`)
 
 ```bash
 git add infrastructure/database/cloudnative-pg/immich/cluster.yaml
@@ -140,6 +149,13 @@ git push
 
 ArgoCD syncs. CNPG ignores `initdb` bootstrap on existing clusters — your data is safe.
 
+### Quick Example Timeline (Immich)
+
+- Before nuke: backups writing to `immich-database-v2`
+- Recovery manifest: restore from `v2`, write new backups to `v3`
+- After recovery: normal manifest with `initdb` active, backup still on `v3`
+- Next DR event: restore from `v3`, then bump backup target to `v4`
+
 ## Troubleshooting
 
 ### "Expected empty archive"

docs/vpa-resource-optimization.md

@@ -438,6 +438,25 @@ kubectl logs -n goldilocks -l app.kubernetes.io/name=goldilocks,app.kubernetes.i
 kubectl logs -n vertical-pod-autoscaler -l app.kubernetes.io/component=recommender
 ```
 
+## Grafana Dashboards
+
+Two community dashboards are auto-provisioned in Grafana under the **Infrastructure** folder:
+
+| Dashboard | Grafana.com ID | What It Shows |
+|-----------|---------------|---------------|
+| **VPA Recommendations** | [14588](https://grafana.com/grafana/dashboards/14588) | Table of target/lower/upper bounds per container, namespace summary |
+| **K8s Autoscaling VPA** | [22168](https://grafana.com/grafana/dashboards/22168) | Cluster overview with drill-down to pod-level VPA details |
+
+**URL**: https://grafana.vanillax.me → search for "VPA"
+
+These dashboards read VPA metrics exposed by kube-state-metrics (`kube_verticalpodautoscaler_*`). Combined with Goldilocks and `vpa-report.sh`, you have three ways to view VPA data:
+
+1. **Goldilocks dashboard** — per-namespace cards with copy-paste YAML
+2. **Grafana VPA dashboards** — time-series graphs and historical trends
+3. **CLI** — `./scripts/vpa-report.sh` for quick terminal output
+
+---
+
 ## Related Docs
 
 - [Monitoring README](../monitoring/README.md) — metrics-server vs Prometheus pipelines

monitoring/prometheus-stack/values.yaml

@@ -209,6 +209,14 @@ grafana:
         gnetId: 20417
         revision: 3
         datasource: Prometheus
+      vpa-recommendations:
+        gnetId: 14588
+        revision: 5
+        datasource: Prometheus
+      vpa-autoscaling:
+        gnetId: 22168
+        revision: 1
+        datasource: Prometheus
   # Additional data sources configuration
   additionalDataSources:
     - name: Loki