Les termes « surveillance » (monitoring) et « observabilité » (observability) sont souvent employés de manière interchangeable dans les discussions portant sur les bases de données et les infrastructures. Pourtant, ils désignent deux concepts sensiblement différents. Bien comprendre cette distinction ne relève pas d’un simple débat terminologique. Elle détermine la façon dont vous instrumentez vos systèmes, les questions auxquelles vous pouvez répondre en cas d'incident et, en fin de compte, la rapidité avec laquelle vous résolvez les problèmes avant qu’ils n’affectent les utilisateurs finaux.
Qu'est-ce que la surveillance des bases de données ?
La surveillance consiste à suivre un ensemble prédéfini de métriques au fil du temps et à déclencher une alerte lorsque ces métriques franchissent certains seuils. Elle répond à la question : y a-t-il un problème ? Un système de surveillance observe des indicateurs tels que l'utilisation du processeur (CPU) et de la mémoire, les connexions actives, les entrées/sorties disque et le débit des requêtes. Lorsqu'une de ces valeurs dépasse un seuil que vous avez configuré — par exemple, une utilisation du processeur supérieure à 90 % pendant cinq minutes d'affilée —, une alerte est déclenchée.
La surveillance est, par nature, réactive. Vous décidez à l'avance ce qu'il faut mesurer, vous définissez des seuils en fonction de vos attentes et vous attendez d'être averti lorsque ces attentes ne sont pas satisfaites. Cette approche fonctionne bien pour les modes de défaillance connus : si votre base de données a déjà subi une panne en raison de l’épuisement du pool de connexions, vous surveillez le nombre de connexions et déclenchez une alerte avant que cet épuisement ne se reproduise. La surveillance est essentielle, éprouvée et bien maîtrisée. Sa limite réside dans le fait qu’elle ne détecte que les problèmes que vous avez anticipés.
Qu'est-ce que l'observabilité des bases de données ?
L'observabilité est un concept plus large emprunté à la théorie du contrôle et popularisé en génie logiciel par l'essor des systèmes distribués. Alors que la surveillance (*monitoring*) vous signale qu'un problème survient, l'observabilité vous aide à en comprendre la cause. Un système observable est conçu pour exposer suffisamment d'informations sur son état interne — via des métriques, des journaux et des traces — pour vous permettre d'analyser son comportement, même face à une défaillance inédite et inattendue.
La distinction essentielle réside dans le fait que l’observabilité est proactive et exploratoire. Il ne s'agit pas simplement d'attendre que des seuils prédéfinis soient atteints ; vous construisez un système suffisamment riche en données pour poser des questions variées et spécifiques sur son fonctionnement interne. Dans le cas des bases de données, cela peut impliquer de corréler un pic de latence des requêtes avec le verrouillage d'une table spécifique, de suivre une requête lente tout au long de son plan d'exécution, ou de comparer le comportement d'une instance à des références historiques afin de détecter une dérive subtile avant qu'elle ne provoque une panne.
L'observabilité ne remplace pas la surveillance, elle la complète. Voyez la surveillance comme un système d'alarme et l'observabilité comme un réseau de caméras de sécurité : l'alarme vous signale l'ouverture d'une porte, tandis que les caméras vous indiquent qui l'a ouverte, quelle direction a été prise et ce que la personne transportait.
Pourquoi cette distinction est importante en pratique
Les environnements de bases de données modernes ont considérablement gagné en complexité. Les équipes gèrent souvent simultanément plusieurs moteurs de bases de données, des instances hébergées dans le cloud, des répliques de lecture et diverses topologies de réplication. Dans de tels environnements, une simple alerte basée sur un seuil d'utilisation du processeur suffit rarement à diagnostiquer un problème. La cause première peut être une requête unique à longue durée d'exécution, une jointure mal optimisée introduite lors d'un déploiement récent ou une contention de verrous provoquée par un schéma de trafic inhabituel. Retracer cette chaîne de causalité nécessite de l'observabilité, et pas seulement de la surveillance.
Concrètement, cela signifie que les équipes qui se limitent à la surveillance se retrouvent à réagir aux alertes sans disposer des données nécessaires pour les diagnostiquer rapidement. L'observabilité comble cette lacune en garantissant que toutes les données utiles à l'analyse sont déjà disponibles lorsqu'un problème survient.
Navicat Monitor pour combler le fossé
Navicat Monitor 3 est un excellent exemple d'outil qui réunit à la fois des fonctionnalités de surveillance et d'observabilité au sein d'un seul et même produit, ce qui le rend particulièrement pratique pour les équipes qui ne souhaitent pas avoir à combiner plusieurs solutions distinctes.
En matière de surveillance, Navicat Monitor s'appuie sur une architecture sans agent : il se connecte à vos instances de base de données via SSH ou SNMP sans nécessiter l'installation de logiciels sur les serveurs eux-mêmes. L'outil collecte des métriques à intervalles réguliers — notamment la charge CPU, l'utilisation de la mémoire vive (RAM) et du disque, les entrées/sorties réseau, les verrous de tables, etc. — et les présente sous forme de graphiques en temps réel et historiques. Point essentiel : il prend en charge MySQL, MariaDB, PostgreSQL et SQL Server, ainsi que les bases de données hébergées dans le cloud, notamment Amazon RDS, Amazon Aurora, Google Cloud, Oracle Cloud et Microsoft Azure. Des seuils d’alerte personnalisés peuvent être configurés pour chaque métrique avec des notifications envoyées par e-mail, SMS ou SNMP, et des groupes de serveurs peuvent être organisés de manière à ce que les configurations d’alerte soient appliquées de manière cohérente sur toutes les instances concernées.
C’est grâce à son « Analyseur de requêtes » et à son « Profileur SQL » que Navicat Monitor s’impose dans le domaine de l’observabilité. L'Analyseur de requêtes fournit une représentation graphique des données des journaux de requêtes, permettant de visualiser les statistiques d'activité, d'analyser des instructions SQL spécifiques et d'identifier rapidement les requêtes à exécution longue. Plutôt que de se contenter de signaler une dégradation des performances des requêtes, il vous offre les outils nécessaires pour comprendre quelles requêtes en sont responsables et pourquoi. Le « SQL Profiler », disponible pour les instances PostgreSQL, va encore plus loin : il prend en charge la création de traces planifiées qui collectent des données d’exécution des requêtes en fonction des filtres que vous définissez, et les plans d’exécution de chaque requête tracée peuvent être consultés sous forme visuelle, graphique ou textuelle. Cette combinaison d'approches correspond précisément à ce qu’est l’observabilité dans la pratique : la capacité à examiner en profondeur le comportement interne du système à différents de détail.
Navicat Monitor prend également en charge des métriques personnalisées, permettant aux équipes de rédiger leurs propres requêtes pour collecter des données de performance spécifiques à leur environnement et de configurer des alertes basées sur les résultats. Cette extensibilité constitue une caractéristique majeure en matière d'observabilité : elle permet d'adapter l'outil pour mettre en évidence les indicateurs d'état interne les plus pertinents pour votre charge de travail spécifique, au-delà des simples signaux génériques d'intérêt général.
Conclusion
La surveillance vous signale les anomalies, tandis que l'observabilité vous apporte le contexte nécessaire pour en comprendre les causes. Ces deux approches sont indispensables ; les équipes de gestion de bases de données les plus performantes les considèrent comme complémentaires plutôt que concurrentes. Des outils tels que Navicat Monitor 3 — qui associent alertes en temps réel et surveillance par seuils à une analyse approfondie des requêtes et au suivi de leur exécution — permettent de combler le fossé entre ces deux démarches et de passer d'une simple réaction aux problèmes à une véritable compréhension et prévention de ceux-ci.
