🔝 Retour au Sommaire
Imaginez que vous pilotez un avion. Sur votre tableau de bord, parmi des dizaines d'indicateurs, certains sont absolument critiques : l'altitude, la vitesse, le niveau de carburant, la température des moteurs. Ces quelques métriques vous disent immédiatement si tout va bien ou si vous devez agir.
PostgreSQL, c'est pareil. Il existe des centaines de statistiques disponibles, mais seulement quelques métriques vitales vous donnent l'essentiel de l'information sur la santé de votre base de données.
Dans ce chapitre, nous allons découvrir les 5 métriques vitales que tout administrateur de base de données doit surveiller en priorité. Ce sont les indicateurs qui font la différence entre un système performant et un système qui va bientôt rencontrer des problèmes.
Une métrique vitale est un indicateur de performance qui :
- Révèle l'état de santé global du système
- Prédit les problèmes avant qu'ils deviennent critiques
- Guide les décisions d'optimisation
- Se lit rapidement et se comprend facilement
Quand vous allez chez le médecin, il prend d'abord vos signes vitaux :
| Signe Vital | Signification | Alerte si... |
|---|---|---|
| Température | Infection/Inflammation | > 38°C |
| Tension artérielle | Santé cardiovasculaire | > 140/90 |
| Fréquence cardiaque | Effort du cœur | > 100 bpm au repos |
| Saturation O₂ | Oxygénation | < 95% |
Ces 4 mesures simples donnent une vision globale de votre état de santé. Le médecin n'a pas besoin de faire 50 examens pour savoir si vous allez bien.
PostgreSQL a aussi ses signes vitaux !
Les métriques vitales agissent comme un système d'alerte précoce.
Sans monitoring :
Jour 1 : Tout semble normal
Jour 5 : Quelques lenteurs occasionnelles
Jour 10 : Base de données très lente
Jour 15 : 💥 Crash complet - Clients furieux - Urgence 3h du matin
Avec monitoring des métriques vitales :
Jour 1 : Alerte "Cache Hit Ratio en baisse" → Investigation
Jour 2 : Identification du problème (bloat) → Action planifiée
Jour 3 : Correction appliquée en heures creuses
Jour 4+ : Tout fonctionne normalement ✅
Bénéfice : Vous passez de la gestion de crise à la gestion proactive.
Vous ne pouvez pas tout optimiser en même temps. Les métriques vitales vous disent où agir en priorité.
Exemple de dashboard :
Cache Hit Ratio : 99.2% 🟢 → OK, ne rien faire
Bloat : 8% 🟢 → OK, surveiller
I/O Wait : 45% 🔴 → PRIORITÉ 1 : Problème critique !
Connexions actives : 65% 🟡 → À surveiller
Checkpoints forcés : 5% 🟢 → OK
Conclusion immédiate : Concentrez vos efforts sur l'I/O avant tout le reste.
Quand vous faites une modification (ajout d'index, changement de configuration), les métriques vitales vous disent si ça a fonctionné.
Exemple :
AVANT l'ajout d'un index :
- Cache Hit Ratio : 92%
- I/O Wait : 25%
- Requêtes lentes : 150/min
APRÈS l'ajout d'un index :
- Cache Hit Ratio : 97% ✅ +5%
- I/O Wait : 12% ✅ -13%
- Requêtes lentes : 20/min ✅ -87%
Verdict : L'optimisation est un succès, mesurable et quantifiable.
Les métriques vitales permettent d'expliquer simplement la situation aux non-techniciens.
Mauvaise communication (trop technique) :
"Le ratio de dirty pages dans le shared buffer pool a augmenté de 15 points de base suite à une augmentation du facteur de charge transactionnelle..."
Bonne communication (métrique vitale) :
"Notre base de données utilise 95% de ses connexions disponibles. Nous devons passer à un système de pooling cette semaine pour éviter une saturation."
Voici les 5 métriques que nous allons explorer en détail dans les sections suivantes :
Question : Mes données sont-elles en mémoire ou PostgreSQL attend-il constamment après le disque ?
Indicateur : Pourcentage de lectures servies depuis la RAM vs le disque
Seuil cible : > 99%
Impact si problème :
- Requêtes lentes
- I/O élevé
- Serveur qui "rame"
Ce que vous apprendrez :
- Comment mesurer le cache hit ratio
- Interpréter les résultats
- Augmenter l'efficacité du cache
- Optimiser shared_buffers
Question : Ma base de données contient-elle beaucoup d'espace mort inutilisé ?
Indicateur : Pourcentage de "déchets" dans vos tables et index
Seuil cible : < 20%
Impact si problème :
- Tables anormalement volumineuses
- Performances dégradées progressivement
- Sauvegardes plus longues
- Cache moins efficace
Ce que vous apprendrez :
- Comprendre le bloat et pourquoi il se produit
- Le mesurer précisément
- Le prévenir avec VACUUM
- Le corriger si nécessaire
Question : Mon système passe-t-il trop de temps à attendre le disque ?
Indicateur : Pourcentage de temps CPU en attente I/O + latence disque
Seuil cible : I/O Wait < 10%, Latency < 5ms (SSD)
Impact si problème :
- Lenteurs généralisées
- CPU inactif mais système lent
- Gaspillage de ressources
Ce que vous apprendrez :
- Mesurer l'I/O Wait avec iostat et top
- Comprendre la latence disque
- Identifier les requêtes problématiques
- Optimiser (SSD, index, cache)
Question : Ai-je trop ou pas assez de connexions disponibles ?
Indicateur : Nombre de connexions actives vs limite maximale
Seuil cible : < 70% de max_connections
Impact si problème :
- Erreurs "too many clients"
- Timeouts fréquents
- Saturation mémoire
- Performances imprévisibles
Ce que vous apprendrez :
- Comprendre le coût d'une connexion
- Détecter les connection leaks
- Implémenter PgBouncer (pooling)
- Dimensionner correctement
Question : Mes checkpoints causent-ils des ralentissements périodiques ?
Indicateur : Fréquence et durée des checkpoints + volume WAL
Seuil cible : Checkpoints forcés < 10%, durée < timeout
Impact si problème :
- Pics de lenteur réguliers (ex: toutes les 5 min)
- I/O burst pendant checkpoints
- Expérience utilisateur dégradée
Ce que vous apprendrez :
- Comprendre le WAL et les checkpoints
- Configurer max_wal_size et checkpoint_timeout
- Lisser les écritures
- Monitorer efficacement
Approche recommandée :
- Lisez l'introduction (cette page) pour comprendre la vue d'ensemble
- Étudiez chaque métrique dans l'ordre (14.6.1 → 14.6.5)
- Appliquez immédiatement : Mesurez ces métriques sur votre système
- Créez un dashboard simple avec ces 5 indicateurs
- Revenez régulièrement : Ces métriques doivent devenir une seconde nature
Temps estimé : 5-8 heures pour maîtriser les 5 métriques
Utilisation en référence :
- Consultez directement la métrique qui vous intéresse
- Utilisez les requêtes SQL fournies
- Intégrez les alertes recommandées dans votre monitoring
- Adaptez les seuils à votre contexte spécifique
Focus opérationnel :
- Automatisez la collecte de ces métriques
- Créez des dashboards Grafana
- Configurez des alertes PagerDuty/Slack
- Documentez vos seuils dans des runbooks
5 métriques essentielles
- Cache Hit Ratio
- Bloat
- I/O Wait
- Connexions
- Checkpoints
Fréquence : Surveillance continue (temps réel)
Action : Si l'une est dans le rouge → Investigation immédiate
20-30 métriques importantes
- Query duration (p50, p95, p99)
- Table sizes
- Index usage
- Replication lag
- Transaction rate
- etc.
Fréquence : Consultation quotidienne
Action : Tendances et optimisations planifiées
100+ métriques spécifiques
- Toutes les vues pg_stat_*
- Métriques système complètes
- Métriques applicatives
Fréquence : Consultation lors d'investigations
Action : Debug approfondi et troubleshooting
Principe 80/20 : 80% de la valeur vient des 20% de métriques (les métriques vitales).
Chaque section fournit des requêtes SQL à copier-coller.
Avantages :
- ✅ Pas d'installation
- ✅ Fonctionne partout
- ✅ Apprentissage des concepts
Inconvénients :
- ❌ Manuel (pas de temps réel)
- ❌ Pas d'historique
- ❌ Pas d'alertes
Interface graphique avec monitoring intégré.
Avantages :
- ✅ Visuel et intuitif
- ✅ Dashboard simple
- ✅ Gratuit
Inconvénients :
- ❌ Limité en fonctionnalités
- ❌ Pas d'alertes avancées
Architecture :
PostgreSQL → postgres_exporter → Prometheus → Grafana
Avantages :
- ✅ Open source
- ✅ Très puissant
- ✅ Alertes complètes
- ✅ Historique long terme
- ✅ Standard de l'industrie
Effort : 1-2 jours d'installation et configuration
AWS CloudWatch RDS, Azure Monitor, GCP Cloud Monitoring
Avantages :
- ✅ Intégré si vous utilisez RDS/Cloud SQL
- ✅ Zéro configuration
- ✅ Alertes automatiques
Inconvénients :
- ❌ Coût supplémentaire
- ❌ Moins de flexibilité
DataDog, New Relic, AppDynamics
Avantages :
- ✅ Tout-en-un
- ✅ Support professionnel
- ✅ IA et prédictions
Inconvénients :
- ❌ Coûteux (50-500$/mois)
Objectif : Connaître vos métriques actuelles
Actions :
- Exécuter les requêtes de mesure pour chaque métrique
- Noter les valeurs dans un tableau
- Comparer aux seuils recommandés
- Identifier les métriques "dans le rouge"
Durée : 30 minutes
Objectif : Déterminer quoi corriger en premier
Règle de priorisation :
Priorité 1 (🔴) : Critique - Action sous 24h
- Cache Hit Ratio < 90%
- I/O Wait > 30%
- Connexions > 90%
Priorité 2 (🟠) : Important - Action sous 1 semaine
- Cache Hit Ratio < 95%
- Bloat > 30%
- Checkpoints forcés > 30%
Priorité 3 (🟡) : À surveiller - Action planifiable
- Toute métrique en zone orange
Objectif : Comprendre la cause racine
Approche :
- Lire la section détaillée de la métrique problématique
- Exécuter les requêtes de diagnostic fournies
- Identifier la cause (requête lente, bloat, config, etc.)
- Documenter vos découvertes
Durée : 1-4 heures selon complexité
Objectif : Corriger le problème
Types d'actions :
Actions immédiates (< 1 heure) :
- Ajout d'index
- VACUUM manuel
- Terminer connexions zombie
- Ajustement configuration (reload)
Actions planifiées (fenêtre maintenance) :
- VACUUM FULL
- REINDEX
- Migration SSD
- Redimensionnement serveur
Objectif : Vérifier que la correction a fonctionné
Actions :
- Re-mesurer la métrique après l'action
- Comparer avant/après
- Surveiller pendant 24-48h
- Documenter le résultat
Critère de succès : Métrique revenue dans la zone verte
Objectif : Éviter que le problème se reproduise
Actions :
- Mettre en place alertes automatiques
- Documenter dans un runbook
- Automatiser la correction si possible
- Revoir la configuration pour prévenir récurrence
Voici un exemple de dashboard minimaliste mais efficace que vous pouvez créer :
Section 1 : Métriques Vitales (Gauges)
┌─────────────────────────────────────────────────┐
│ Cache Hit Ratio Bloat I/O Wait │
│ [99.2%]🟢 [12%]🟢 [8%]🟢 │
│ │
│ Connexions Checkpoints Forcés │
│ [45/100]🟢 [7%]🟢 │
└─────────────────────────────────────────────────┘
Section 2 : Graphiques Temporels
Cache Hit Ratio (24h)
100% |----------------------------------------
95% |========================================
90% |----------------------------------------
+----------------------------------------
0h 6h 12h 18h 24h
Stable à 99% toute la journée ✅
I/O Wait % (24h)
30% |----------------------------------------
15% | ██
5% |████████████████████████████████████████
0% +----------------------------------------
0h 6h 12h 18h 24h
Pic à 15% pendant checkpoint (normal) ✅
Section 3 : Top N
Top 5 Tables par Bloat Top 5 Requêtes I/O
1. orders : 35% 🔴 1. SELECT ... : 5.2s
2. logs : 28% 🟠 2. UPDATE ... : 3.8s
3. sessions : 15% 🟡 3. INSERT ... : 2.1s
4. products : 8% 🟢 4. DELETE ... : 1.5s
5. users : 5% 🟢 5. SELECT ... : 1.2s
Légende Couleurs :
- 🟢 Vert : OK
- 🟡 Jaune : À surveiller
- 🟠 Orange : Attention
- 🔴 Rouge : Action requise
Temps réel (Grafana/DataDog) :
- Dashboard affiché en permanence dans la salle de contrôle
- Alertes envoyées automatiquement
- Consultation réflexe en cas de problème
Chaque matin :
- Consulter le dashboard des métriques vitales
- Vérifier que tout est dans le vert
- Noter les tendances (amélioration/dégradation)
- Si orange/rouge : Planifier investigation
Chaque lundi :
- Analyser les tendances de la semaine
- Identifier les patterns (jour/heure problématiques)
- Planifier optimisations si nécessaire
- Documenter les incidents résolus
Début de chaque mois :
- Analyse approfondie des 5 métriques
- Comparaison mois N vs mois N-1
- Ajustement des seuils d'alerte si besoin
- Planning d'optimisations pour le mois
- Rapport pour le management
Voici une checklist pour bien démarrer avec les métriques vitales :
- Lire cette introduction complètement
- Choisir un outil de monitoring (commencer simple)
- S'assurer d'avoir accès en lecture à PostgreSQL
- Créer un document pour noter les résultats
- Mesurer le Cache Hit Ratio
- Mesurer le Bloat des tables principales
- Mesurer l'I/O Wait
- Compter les connexions actives
- Vérifier les statistiques de checkpoints
- Documenter toutes les valeurs (baseline)
- Identifier les métriques problématiques
- Prioriser les actions (🔴 > 🟠 > 🟡)
- Lire en détail les sections concernées
- Planifier les corrections
- Appliquer les corrections prioritaires
- Re-mesurer après chaque action
- Valider les améliorations
- Documenter ce qui a fonctionné
- Mettre en place un dashboard
- Configurer des alertes automatiques
- Établir une routine de consultation
- Former l'équipe
- Revue quotidienne (10 min)
- Revue hebdomadaire (30 min)
- Revue mensuelle (2h)
- Ajustements et optimisations continues
En maîtrisant ces 5 métriques vitales, vous serez capable de :
- ✅ Diagnostiquer 90% des problèmes de performance PostgreSQL
- ✅ Mesurer précisément la santé de votre base de données
- ✅ Optimiser de manière ciblée et efficace
- ✅ Prévenir les pannes avant qu'elles surviennent
- ✅ Expliquer les problèmes en termes compréhensibles
- ✅ Monitorer efficacement en production
- ✅ Alerter au bon moment (ni trop, ni trop peu)
- ✅ Prioriser les efforts d'optimisation
- ✅ Documenter l'état de santé du système
- ✅ Communiquer avec les stakeholders
- ✅ Proactivité : Agir avant que ça casse
- ✅ Data-driven : Décisions basées sur des mesures
- ✅ Pragmatisme : Focus sur ce qui compte vraiment
- ✅ Confiance : Savoir où regarder quand il y a un problème
Vous êtes maintenant prêt à plonger dans le détail de chaque métrique vitale.
Ordre recommandé :
- Cache Hit Ratio (14.6.1) - Le plus universel et le plus impactant
- I/O Wait et Disk Latency (14.6.3) - Souvent lié au cache
- Table et Index Bloat (14.6.2) - Affecte cache et I/O
- Connexions et Pools (14.6.4) - Critique pour la disponibilité
- Checkpoints et WAL (14.6.5) - Optimisation avancée
Chaque section est autonome et peut être consultée indépendamment, mais elles sont aussi interconnectées : améliorer l'une impacte souvent les autres positivement.
Bon monitoring et bonnes optimisations ! 🚀
✅ 5 métriques vitales suffisent pour 90% du monitoring PostgreSQL
✅ Principe 80/20 : Ces quelques métriques donnent l'essentiel de l'information
✅ Monitoring proactif : Détecter les problèmes avant qu'ils deviennent critiques
✅ Mesure → Action → Validation : Approche méthodique et quantifiable
✅ Commencer simple : Requêtes SQL manuelles puis automatisation progressive
✅ Dashboard minimal : 5 indicateurs bien choisis > 50 indicateurs inutilisés
✅ Routine essentielle : Consultation quotidienne (10 min) + revue hebdomadaire (30 min)
✅ Chaque métrique a un seuil : Savoir ce qui est OK, à surveiller, ou critique