Exploitation et supervision¶
admin@pve:~# ls exploitation/ | wc -l → 7 pages · 7 disponibles
Routines Day 2, notifications, supervision, capacité, PRA.
Cette rubrique est le cœur du Day 2 : ce que l'équipe d'exploitation fait chaque semaine pour garder un cluster Proxmox sain, comment elle est prévenue quand quelque chose casse, et comment elle diagnostique avant d'appliquer un runbook ou d'ouvrir un ticket. Elle s'adresse aux admins système et aux équipes d'astreinte N1/N2 ; les deux dernières pages (capacité, PRA) visent aussi les responsables infrastructure.
Ce que vous saurez faire¶
- Dérouler en 15 minutes une routine hebdomadaire couvrant cluster, stockage, sauvegardes, copie MSP, mises à jour et certificats.
- Configurer les notifications natives (SMTP, webhook, Gotify) et des matchers qui envoient chaque alerte à la bonne équipe.
- Raccorder le cluster à Zabbix, Prometheus ou InfluxDB avec un compte de service en lecture seule.
- Retrouver la trace d'un incident avec
journalctl, les journaux de tâches et les logs Ceph. - Partir d'un symptôme (VM lente, nœud grisé, sauvegarde en échec) pour aboutir au bon runbook.
- Anticiper l'achat de disques ou de nœuds avec la règle N+1, et tester un plan de reprise.
Prérequis¶
- Proxmox en 15 minutes : PVE, PBS, PMG, PDM
- Le périmètre de votre contrat MSP
- Quorum et votes : 2, 3, 4, 5 nœuds
- Rétention, prune, garbage collection, verify
Ordre de lecture conseillé¶
- Routine hebdomadaire de l'admin Proxmox (15 min)
- Lire les logs : journalctl, task log, /var/log/pve
- Notifications natives : cibles mail, webhook, Gotify, matchers
- Superviser avec Zabbix / Prometheus / InfluxDB metric server
- Diagnostic par symptôme : VM lente, nœud grisé, backup en échec
- Plan de capacité : quand ajouter un nœud ou des disques
- PRA / PCA : cluster distant, sync PBS, test de bascule
Runbooks liés : RB-01 · état Ceph, RB-09 · nœud grisé et quorum, RB-10 · VM verrouillée, RB-14 · sauvegarde en échec, RB-15 · sync MSP, et le parcours Je suis d'astreinte.
Notions clés¶
| Terme | Définition |
|---|---|
| Cible de notification | Destination d'une alerte : sendmail, SMTP, Gotify ou webhook |
| Matcher | Règle qui choisit quels événements (type, sévérité, horaire) partent vers quelles cibles |
| UPID | Identifiant unique d'une tâche PVE, qui permet d'en lire le journal |
| Metric Server | Envoi des métriques par PVE vers InfluxDB ou Graphite (Datacenter → Metric Server) |
| N+1 | Capacité suffisante pour faire tourner toutes les VMs avec un nœud en moins |
| nearfull | Seuil Ceph (85 % par défaut) au-delà duquel un OSD déclenche une alerte |
| RPO / RTO | Perte de données et durée d'arrêt maximales admises lors d'une reprise |
Les pages de la rubrique¶
| Page | Format | Phase | Niv. | Statut |
|---|---|---|---|---|
| Routine hebdomadaire de l'admin Proxmox (15 min) | Checklist | Day 2 · Exploiter | 1 | Rédigé |
| Lire les logs : journalctl, task log, /var/log/pve | Fiche | Day 2 · Exploiter | 1 | Rédigé |
| Notifications natives : cibles mail, webhook, Gotify, matchers | Procédure | Day 2 · Exploiter | 2 | Rédigé |
| Superviser avec Zabbix / Prometheus / InfluxDB metric server | Procédure | Day 2 · Exploiter | 2 | Rédigé |
| Diagnostic par symptôme : VM lente, nœud grisé, backup en échec | Arbre de décision | Day 2 · Exploiter | 2 | Rédigé |
| Plan de capacité : quand ajouter un nœud ou des disques | Cours | Day 2 · Exploiter | 3 | Rédigé |
| PRA / PCA : cluster distant, sync PBS, test de bascule | Cours + runbook | Day 2 · Exploiter | 3 | Rédigé |