Infra de A à Z 041 - Monitoring: e.g., backups, etc.

TL;DR

Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Monitoring: e.g., backups, etc.. Concentrer l épisode sur PostgreSQL: installation, réplication, failover, sauvegarde ou restauration selon "Monitoring: e.g., backups, etc.".

La vidéo de référence

Vidéo: https://www.youtube.com/watch?v=y_9FcylrED0

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X

Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 40-monitoring-consul-backups-restic.

Objectif précis de l épisode

Concentrer l épisode sur PostgreSQL: installation, réplication, failover, sauvegarde ou restauration selon "Monitoring: e.g., backups, etc.".

Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.

Monitoring: e.g., backups, etc.: c est quoi exactement ?

Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: terraform, openstack, consul, monitoring, postgresql.

Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Monitoring: e.g., backups, etc..

Ce que la vidéo cherche à modifier

brancher les métriques utiles
adapter la configuration de collecte ou de stockage
rendre le résultat visible dans Grafana ou dans les règles d alerte
séparer configuration base, supervision et sauvegarde
vérifier le rôle primaire/secondaire ou la stratégie de backup
documenter la preuve de restauration ou de bascule

Indices extraits des slides

Monitoring – Custom Metrics – Backups consul
store each file as an object
use metadatas to organize them
ideal for large amount of datas (infinity)
Different from block storage (disks for instance)

Découvrez Infra de A à Z 031 - Consul : création de services via ansible

Notions et définitions des outils

terraform: Terraform décrit l infrastructure comme du code. Le provider OpenStack transforme des ressources HCL en objets cloud: réseaux, routeurs, instances, volumes, groupes de sécurité.
openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
consul: Consul apporte service discovery, DNS interne, health checks et catalogue de services. Il relie machines, proxy, monitoring et automatisation.
monitoring: Le monitoring collecte métriques, alertes et dashboards. Node exporter, vmagent, VictoriaMetrics, VMAlert, Alertmanager, Karma et Grafana couvrent collecte, stockage, règles, notification et visualisation.
postgresql: PostgreSQL est le SGBD relationnel de la plateforme. La série aborde installation, réplication, failover, utilisateurs, sauvegardes, PITR et monitoring.

Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.

Points clés à retenir pour cet épisode

Comprendre le rôle de Monitoring: e.g., backups, etc. dans la progression globale de l infrastructure.
Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
Séparer clairement la création des ressources cloud du paramétrage applicatif.
Conserver une preuve de fonctionnement via métriques, dashboards ou alertes.

Approfondissement spécifique

Pour Monitoring: e.g., backups, etc., le sujet précis est le trajet de la métrique: exposition par un exporter ou un composant, découverte par le collecteur, stockage, requête PromQL puis visualisation ou alerte.

Un dashboard ne valide pas à lui seul l observabilité. Il faut remonter à la target, vérifier la fraîcheur des séries, tester une requête représentative et s assurer que l alerte repose sur un signal actionnable.

Pour Monitoring: e.g., backups, etc., le sujet PostgreSQL doit être lu autour de l état: données, réplication, sauvegarde, restauration ou failover. La réussite ne se limite pas au service démarré.

La preuve dépend du thème: une requête SQL pour l installation, un retard de réplication pour le cluster, une restauration pour le backup, ou une bascule contrôlée pour le failover.

Découvrez Infra de A à Z 107 - Monitoring : un vmcluster victoriametrics

Exemple de code ou configuration du dépôt

openstack ec2 credentials list
openstack ec2 credentials create

Cet extrait doit être lu comme un support pédagogique. Avant de l utiliser tel quel, vérifiez les variables, noms de réseau, plages CIDR, identifiants, secrets, régions, images et règles d exposition.

Chemin de diagnostic recommandé

vérifier que les targets sont up
contrôler une requête PromQL représentative
ouvrir le dashboard ou l alerte concernée
tester une connexion SQL
vérifier réplication ou backup
contrôler les métriques PostgreSQL utiles
Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.

Répertoires et commandes utiles

Répertoire support: 40-monitoring-consul-backups-restic

Commande repérée: restic init
Commande repérée: restic backup test/
Commande repérée: restic backup /tmp/consul-backup.bck
Commande repérée: restic restore b4412403 --target /tmp/ --host consul3
Commande repérée: restic forget \

Pièges fréquents

déployer un exporter sans scrape
créer un dashboard sans métrique stable
alerter sur un signal trop bruité
considérer un backup non restauré comme fiable
ne pas surveiller la réplication
mélanger droits applicatifs et droits admin

Liens utiles externes

Liens internes conseillés

Parcours Kubernetes pour relier la partie cluster et orchestration.
Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.
RabbitMQ et workloads stateful pour comparer stockage, redémarrage et état applicatif.

Pour continuer, lire Infra A à Z 042 – Monitoring : ansible déploiement (ex : backups consul).

FAQ

Pourquoi utiliser Terraform et Ansible ensemble ?

Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.

Pourquoi Infomaniak/OpenStack dans cette série ?

Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.

Que faut-il sécuriser en premier ?

Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.

Comment savoir si une étape est terminée ?

Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.

Conclusion

L épisode 41 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.