La supervision d’une base doit aider à expliquer une lenteur, une erreur ou une saturation. Quelques indicateurs reliés aux parcours utilisateurs valent mieux qu’un tableau rempli de compteurs isolés.
Observer les requêtes
Suivez durée, volume, erreurs et taux de succès. Distinguez la moyenne des percentiles élevés, car une minorité de requêtes très lentes peut gêner les utilisateurs sans modifier beaucoup la moyenne. Enregistrez l’endpoint ou l’opération sans inclure de données privées.
Repérez les requêtes qui augmentent après un déploiement ou une croissance de table. Conservez le plan d’exécution lorsque le moteur le permet, mais évitez un mode de diagnostic trop verbeux en permanence.
Contrôler les ressources
Surveillez connexions, verrous, mémoire, stockage et espace temporaire. Une base peut ralentir parce que le pool de connexions est épuisé alors que le CPU reste modéré. Reliez chaque limite à une action documentée.
L’espace disponible doit déclencher une alerte avant la panne. La durée de rétention des journaux et des sauvegardes doit être incluse dans l’estimation, car elle peut consommer le même volume ou un service associé.
Suivre la réplication et les sauvegardes
Si la base utilise une réplica, observez le retard et les erreurs de synchronisation. Une réplica en retard ne doit pas être présentée comme une copie prête à reprendre la production. Testez les lectures et le changement de rôle selon la configuration retenue.
Vérifiez la réussite des sauvegardes, leur âge et le dernier test de restauration. Une sauvegarde qui n’a jamais été restaurée ne donne pas la durée réelle de reprise. Consultez le guide de restauration.
Relier les signaux à l’application
Ajoutez un identifiant de requête entre API et base. Quand une page ralentit, l’équipe doit pouvoir relier le temps passé dans l’application à celui passé dans la base. Un dashboard séparé par service rend la comparaison plus simple.
Documentez les seuils de connexion, latence et espace. Les valeurs doivent venir d’une mesure de départ et d’un objectif de service. Les alertes sont détaillées dans l’article sur l’observabilité et les SLO.
Tester sous charge
Reproduisez des requêtes représentatives avec des données de test. Observez la concurrence, les verrous et l’effet des index. Vérifiez que les scripts de charge ne contiennent pas de données client et ne peuvent pas atteindre la production.
Sources : PostgreSQL, monitoring database activity, Microsoft, SQL performance monitoring.