Bases de données

Présentation

Les monitors de base de données se connectent à votre serveur PostgreSQL, MySQL/MariaDB ou MongoDB comme le fait votre application, exécutent une requête et vérifient le résultat. Contrairement à un check TCP sur le port 5432, cela prouve que le serveur accepte les connexions, vous authentifie et répond réellement — et la latence connexion + requête est enregistrée à chaque check.

Trois types de monitor, un seul comportement :

Type	Schémas acceptés	Port par défaut	Requête par défaut
PostgreSQL	postgres://, postgresql://	5432	SELECT 1
MySQL	mysql://, mariadb://	3306	SELECT 1
MongoDB	mongodb://, mongodb+srv://	27017	{ "ping": 1 }

MariaDB parle le protocole MySQL — utilisez le type MySQL.

Fonctionnement

1. L’agent ouvre une connexion vers le serveur (TLS si l’URL le demande) et s’authentifie avec l’utilisateur et le mot de passe du monitor.
2. Il exécute la requête configurée — ou celle par défaut du type.
3. Le résultat est comparé à la vérification du résultat optionnelle. Connexion refusée, échec d’authentification, erreur de requête ou timeout comptent comme un check en échec ; un résultat hors de la valeur attendue aussi.

La latence est le temps complet connexion + requête : une base qui ralentit apparaît comme une tendance sur le graphique du monitor bien avant de cesser de répondre.

Paramètres

Paramètre	Description	Valeur par défaut
URL de connexion	postgres://hote:5432/base?sslmode=require, mongodb://noeud1,noeud2/admin?replicaSet=rs0&tls=true	—
Utilisateur de la base	Identifiant utilisé pour le check	—
Mot de passe de la base	Stocké chiffré	—
Requête de test	Instruction SQL, ou document de commande MongoDB en JSON	SELECT 1 / { "ping": 1 }
Vérification du résultat	Opérateur + valeur attendue appliqués au résultat de la requête (optionnel)	aucune
Ignorer la validation TLS	Accepter un certificat auto-signé	désactivé
Intervalle	Fréquence de vérification	selon le plan
Timeout	Budget fixe du check, connexion + requête (non configurable)	5 s

Où vont les identifiants

Collez l’URL de connexion telle que votre fournisseur vous la donne, identifiants compris. Tout ce qui précède le @ est déplacé dans les champs utilisateur et mot de passe, et l’URL est enregistrée sans :

vous collez    mongodb://monitoring:s3cret@node1.example.net,node2.example.net/admin?replicaSet=rs0&tls=true
URL enregistrée mongodb://node1.example.net,node2.example.net/admin?replicaSet=rs0&tls=true
utilisateur    monitoring        (chiffré)
mot de passe   s3cret            (chiffré)

L’URL est ce qu’affichent la liste des monitors, les messages d’alerte, les pages de statut publiques, le journal d’audit et l’export RGPD. L’utilisateur et le mot de passe sont chiffrés au repos, masqués en *** dans l’API et dans tous les exports, et retirés des messages d’erreur. Cela s’applique à tous les types de monitor — une cible HTTP https://user:password@hote est découpée de la même façon.

Utilisez un utilisateur en lecture seule créé pour le monitoring. La requête s’exécute avec ses privilèges, rien d’autre ne la limite.

TLS

L’URL décide si TLS est utilisé, selon la convention de chaque moteur :

• PostgreSQL — ?sslmode=require (ou verify-ca, verify-full)
• MySQL / MariaDB — ?ssl-mode=REQUIRED (ou tls=true)
• MongoDB — ?tls=true ; les URL mongodb+srv:// utilisent toujours TLS

Le certificat du serveur est validé contre les autorités publiques. Pour un certificat auto-signé, cochez Ignorer la validation du certificat TLS sur le monitor.

Vérification du résultat

Le résultat de la requête est réduit à une seule valeur :

• SQL — la première colonne de la première ligne. SELECT count(*) FROM jobs WHERE status = 'stuck' donne un nombre ; SELECT pg_is_in_recovery() donne t/f.
• MongoDB — le document de réponse de la commande. Choisissez un champ par chemin pointé (ok, members.0.stateStr, repl.setName) ; laissez le chemin vide pour comparer la réponse entière.

Choisissez ensuite un opérateur (==, !=, contains, >, <, >=, <=) et la valeur attendue. Les opérateurs numériques comparent des nombres ; les autres comparent du texte.

Exemples :

Moteur	Requête	Vérification	Signification
PostgreSQL	SELECT count(*) FROM jobs WHERE status='stuck'	< 10	la file de jobs ne s’accumule pas
PostgreSQL	SELECT extract(epoch from now() - pg_last_xact_replay_timestamp())	< 30	retard de réplication < 30 s
MySQL	SELECT count(*) FROM information_schema.processlist	< 200	moins de 200 connexions
MongoDB	{ "replSetGetStatus": 1 }	members.0.stateStr == PRIMARY	le nœud 0 est le primaire
MongoDB	{ "serverStatus": 1 }	connections.current < 500	moins de 500 connexions

Sans vérification du résultat, se connecter et exécuter la requête avec succès constitue le check à lui seul.

Bases privées

Une base non joignable depuis Internet — et la plupart ne devraient pas l’être — est surveillée depuis un agent privé déployé dans votre réseau. Le check est identique ; seul l’agent qui l’exécute change. Les régions publiques refusent les cibles qui résolvent vers des adresses privées.

Métriques

Le temps connexion + requête est enregistré à chaque check et alimente le même graphique de latence, les mêmes percentiles et les mêmes alertes qu’un monitor HTTP.