Imagine que t'es le capitaine d'un navire qui navigue sur l'océan des données. Tu veux pas juste que le bateau avance. Tu veux être sûr qu'il va pas se prendre un iceberg de requêtes lentes, qu'une tempête de verrous va pas te tomber dessus, ou que le navire va pas couler à cause d'une surcharge de connexions. La surveillance de ta base de données, c'est ton radar, ton baromètre et ton sonar, pour éviter les icebergs, les tempêtes et la panique.
Pourquoi et comment surveiller une base de données
La surveillance, ça aide à garder ta base de données stable et à repérer les soucis avant qu'ils te pètent à la figure. Imagine : au lieu de voir ton service planter sans prévenir, tu reçois un signal d'alerte : « Hé, cette requête tourne depuis 30 secondes, y'a un truc qui cloche ». Tu sais à l'avance où ça coince, qui garde un verrou, et à quel moment la base va bientôt étouffer par manque de ressources.
Voilà ce qu'il faut surveiller :
Activité des requêtes et transactions. Surveille le flux des requêtes comme un contrôleur surveille un carrefour. Quelles commandes SQL ralentissent tout le monde ? Qui charge la base à mort ? Ces réponses te permettent d'optimiser sans stress ni panique.
Utilisation des ressources. CPU, RAM et espace disque — c'est comme le carburant et la coque du navire. Si une ressource « fuit » ou est surchargée, tout le bateau peut s'arrêter. La surveillance te montre où ça déborde, et te permet de répartir la charge.
Performance des requêtes. Certaines requêtes SQL sont comme des passagers relous : elles demandent trop, ralentissent tout le monde et râlent tout le temps. La surveillance te montre qui sont les plus « gourmands » — pour pouvoir indexer, réécrire ou remplacer.
Verrous et conflits. Parfois, les requêtes se marchent sur les pieds : l'une garde une ressource, l'autre attend. C'est comme si quelqu'un tient la porte d'un côté, et un autre la tire de l'autre. Surveiller ces verrous permet d'intervenir à temps et de calmer le jeu.
Une bonne surveillance ne te dit pas juste que la base « est vivante ». Elle t'indique où sa vie peut dérailler — et te donne le temps de corriger avant que ça devienne un vrai problème.
Métriques clés pour surveiller PostgreSQL
Pour comprendre l'état de ta base de données, tu dois savoir où regarder. Ces métriques, c'est le « pouls » et la « tension » de ta base. Voici les paramètres principaux :
Nombre de connexions actives.
Combien d'utilisateurs sont connectés en ce moment ? Est-ce qu'ils essaient de casser ta base avec des requêtes débiles ? Par exemple,
pg_stat_activity, dont on parlera dans les prochains cours, montre l'activité en temps réel.Temps d'exécution des requêtes.
Quelles requêtes s'exécutent le plus vite ? Et à l'inverse, lesquelles pensent qu'elles sont déjà à la retraite ?
Utilisation des index.
Si t'as des index mais que tu t'en sers pas, y'a un souci. On va vérifier ça avec
pg_stat_user_indexes.Niveau de verrous et de conflits.
Super utile pour éviter les « Deadlocks » (blocages mutuels).
Charge CPU et utilisation de la mémoire.
Par exemple, combien de ressources de ton serveur sont « bouffées » par PostgreSQL ?
À quoi ça ressemble en pratique ?
Regarde un exemple concret. Voici une requête simple pour connaître la taille d'une base de données précise :
SELECT pg_size_pretty(pg_database_size('nom_de_ta_base')) AS database_size;
Cette petite requête te renverra la taille de la base dans un format lisible — genre 243 MB ou 1.2 GB. Pratique pour voir vite fait si ta base a grossi récemment.
Si tu veux voir la taille de toutes les bases d'un coup — sans devoir les lister une par une — tu peux utiliser ça :
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;
Là, t'as une vue d'ensemble de toutes les bases du serveur — nickel pour l'admin qui surveille l'espace disque et veut repérer les « gourmands » avant de recevoir un mail de l'hébergeur : « Tu n'as plus de place ».
GO TO FULL VERSION