Skip to content

Observability & backup

A monitoring stack, a log pipeline and a backup controller are already installed and running on every cluster, operated by GRN. Metrics are collected from the cluster and from workloads that expose them, Velero takes scheduled backups of whole projects, and alerting runs on the same stack. You do not assemble any of this before deploying.

Two things remain your responsibility: exposing metrics from your application, and defining what "unhealthy" means for it in the form of readiness and liveness probes and alert rules.

What this section will cover

  • Metrics and dashboards
  • Log aggregation and retention
  • Alert routing
  • Backup schedules and restore
  • Snapshots and replication
  • Upgrade and patching cadence

Quick checks

oc get events -n <project> --sort-by=.lastTimestamp
oc logs deployment/<name> -n <project> --tail=100
oc adm top nodes

Backups

WebHosting > Storage > Backups lists whole-project backups taken by Velero, each row showing its phase and age.

The platform already runs scheduled backups of your project. Create Backup takes a point-in-time snapshot on top of that schedule. Take one immediately before a change you may need to roll back.

on-demand-backup.yaml
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: myapp-before-upgrade
  namespace: <your-project>
spec:
  includedNamespaces:
  - <your-project>
  defaultVolumesToFsBackup: true
  snapshotMoveData: true
  storageLocation: ovh-s3
  ttl: 720h0m0s

ttl is how long the backup is kept - 30 days above. defaultVolumesToFsBackup and snapshotMoveData make the backup include persistent volume contents rather than only the Kubernetes objects, which is what the console's form sets for you.

Restore is not a console flow yet

Restoring is not yet self-service. Contact support with the backup name, or run velero restore create --from-backup <name> if you have CLI access.

Velero backups and database backups

Two backup mechanisms run in parallel and cover different recovery scenarios.

PostgreSQL clusters managed by CloudNativePG continuously archive WAL to object storage, independently of Velero, which is what gives PostgreSQL point-in-time recovery. Velero backs up the project as a whole, meaning Kubernetes objects plus volume contents.

Use the database's own backup to rewind a database to a point in time. Use Velero to rebuild a project.