Types de moniteurs

Un moniteur est un contrôle planifié exécuté par une sonde. Tous les types partagent le même squelette — nom, tags, sonde, planning, seuils, alerting — et ne diffèrent que par leur cible et par la façon dont leur résultat est évalué. Cette page est le catalogue : choisissez le type le plus léger qui prouve ce qui vous importe réellement.

Vue d’ensemble

Moniteur URL

Le contrôle synthétique de référence : une requête HTTP(S), entièrement instrumentée.

Ce qu’il mesure

Un moniteur URL ne se contente pas de chronométrer la requête, il la décompose :

Un moniteur URL lent est donc auto-diagnostiquant : un pic sur le DNS est un problème de résolveur, un pic sur le TLS un problème de handshake ou de chaîne de certificats, et un pic sur le traitement serveur, l’application.

Ce qu’il contrôle

Au-delà du temps de réponse, un moniteur URL évalue trois autres choses — chacune optionnelle, chacune produisant son propre statut :

1. Le statut HTTP — tout ce qui sort des 2xx/3xx fait échouer le contrôle.
2. La taille de page — définissez une taille de corps attendue et un opérateur de comparaison (> / <). Pratique pour détecter une page tronquée ou une réponse « réussie » qui a soudain perdu la moitié de son contenu.
3. Les groupes de motifs — des contrôles par expression régulière sur le corps de la réponse. Voir Groupes de motifs plus bas.

Options de connectivité

Configuration typique

Moniteur API

Un moniteur API est un moniteur URL avec un contrôle total de la requête, destiné aux points d’accès REST plutôt qu’aux pages.

La requête

Le verdict

Un moniteur API est évalué sur :

1. Le code de statut HTTP — un 5xx est un échec critique quel que soit le temps.
2. Le temps de réponse face aux seuils Mineur / Majeur / Critique.
3. Les groupes de motifs appliqués au corps de la réponse — c’est là qu’un moniteur API prend toute sa valeur. Plutôt que de prouver seulement que /health a répondu, vous extrayez les valeurs à l’intérieur de la réponse et vous les évaluez.

Identifiants

Ne codez jamais un jeton en dur dans un en-tête si vous pouvez l’éviter. Référencez une configuration d’identifiants ou récupérez le secret depuis un coffre-fort afin que la rotation se fasse en un seul endroit.

Groupes de motifs (URL & API)

Les moniteurs URL et API savent évaluer le contenu de la réponse, pas seulement son temps. Chaque groupe de motifs extrait une valeur avec une expression régulière et la confronte à ses propres seuils Mineur / Majeur / Critique. Le statut du moniteur est le plus grave de tous les groupes et du temps de réponse.

Deux modes

L’expression régulière d’un groupe fonctionne dans l’un des deux modes, choisi automatiquement selon qu’elle contient ou non un groupe de capture :

• Correspondance de contenu — sans (groupe de capture). Un contrôle de présence : le corps doit contenir le motif. Sinon, le moniteur échoue. Ni opérateur, ni seuils. C’est la façon la moins chère d’attraper l’échec classique du « HTTP 200 avec une page d’erreur ».
• Extraction de valeur — avec exactement un (groupe de capture). Le texte capturé devient une valeur à évaluer avec un opérateur et des seuils ; il est tracé et conservé avec son propre historique.

Opérateurs

Laissez un palier vide pour l’ignorer — un groupe peut ne définir qu’un seuil Critique. L'index de correspondance (idx) choisit quelle occurrence du motif lire : 1 la première, 2 le deuxième élément d’un champ répété ou d’un tableau JSON. Chaque ligne dispose d’un interrupteur d’activation : un groupe désactivé conserve ses réglages mais n’est pas évalué et n’enregistre aucun historique.

Exemple

Une API renvoyant {"status":"ok","queue":42,"updated":"2026-07-30T09:15:00Z"} peut être évaluée avec trois groupes :

Pour le format de stockage, voir Configuration du moniteur → Groupes de motifs.

Moniteur base de données

Un moniteur de base de données se connecte, exécute une requête, et évalue à la fois le temps qu’elle a pris et ce qu’elle a renvoyé. C’est le seul type qui lit vos données, ce qui en fait l’outil adéquat pour les contrôles de fraîcheur de données et de fin de traitement qu’aucun contrôle réseau ne peut voir.

Moteurs pris en charge

Ces temps côté moteur apparaissent dans la sortie brute d’un test, ce qui permet de distinguer une requête lente (temps CPU/worker élevé) d’une requête en contention (temps de verrou élevé).

Champs de connexion

Contrôles de colonnes — évaluer le jeu de résultats

Un moniteur de base de données ne s’arrête pas à « la requête a répondu ». Chaque contrôle de colonne prélève une valeur dans le jeu de résultats et l’évalue, exactement comme un groupe de motifs le fait pour URL/API. Le statut du moniteur est le plus grave de tous les contrôles et du temps de requête.

Chaque ligne de la grille Contrôles de colonnes comporte :

Sélecteurs de colonne

Opérateurs

La même liste que les groupes de motifs, plus une entrée vide (presence) qui exige simplement une valeur non NULL dans la cellule :

(presence) · number > · number < · number == · string == · string != · string contains · string not contains · datetime older than

Verdicts intégrés

Certaines issues sont évaluées pour vous sans le moindre seuil :

La distinction compte : CRITIQUE est un verdict sur vos données, ERREUR signifie que le contrôle lui-même est mal configuré.

Exemples

Moniteurs réseau

TCP et UDP

La preuve la plus légère possible qu’un service écoute : composer l’hôte et le port depuis la sonde, et enregistrer si la connexion a réussi et combien de temps elle a pris.

Utilisez-les pour tout ce qui n’a pas de surface HTTP — ports de bases de données, brokers de messages, LDAP, SMTP — et comme premier tri quand un moniteur URL passe au rouge : si le TCP va bien et pas l’URL, le réseau n’est pas votre problème.

Ping

Requête/réponse d’écho ICMP. Elle répond à une autre question que le TCP : non pas « le service est-il debout » mais « l’hôte est-il joignable, et le chemin est-il sain ».

La gigue et la perte sont ce qui rend le Ping utile à côté de tout le reste : elles transforment un vague « l’appli rame » en un problème réseau mesuré.

DNS

Résoudre un nom depuis la sonde et mesurer la durée. Peu coûteux, et cela attrape toute une classe de pannes — un résolveur disparu, un enregistrement supprimé, un changement de TTL malheureux — bien avant qu’elles ne remontent en erreur applicative.

Moniteurs d’équipements

SNMP

Interroger un OID sur un équipement réseau : v1, v2c ou v3 (avec utilisateur, authentification et chiffrement). La valeur devient un statut via un opérateur : number >, number < ou regexp.

SNMP prend aussi en charge les expressions mathématiques qui combinent plusieurs OID en une valeur calculée — trafic total d’interface avec oidIn + oidOut, pourcentage de mémoire avec (used / total) * 100 — et les deltas entre relevés, indispensables pour donner du sens aux compteurs monotones.

WMI

L’équivalent Windows : exécuter une requête WQL dans un espace de noms (par défaut root\CIMV2) et évaluer la valeur renvoyée avec les mêmes opérateurs.

Les deux types embarquent une série d’assistants — OID/requêtes suggérés et vérifiés en direct sur la cible, explorateur de sous-arbre ou de classes, modèles réutilisables, et un bouton Tout tester. Voir Évaluation SNMP et WMI pour le parcours complet.

EUM / Web UI

Le type le plus lourd et le plus fidèle : un parcours navigateur scripté, exécuté sur un vrai Chrome, Firefox ou Edge, chronométré étape par étape.

Un moniteur EUM est le seul type qui mesure ce que l’utilisateur vit réellement, rendu front-end compris. C’est aussi le plus coûteux à exécuter et le plus fragile à maintenir : scriptez les deux ou trois parcours qui portent votre chiffre d’affaires, et couvrez le reste avec des moniteurs URL et API.

Voir la page Moniteur EUM pour la spécification complète, et Opérations sur les moniteurs pour les modes d’exécution navigateur et headless.

Système

Auto-supervision de la machine de la sonde : utilisation CPU, mémoire et disque, chacune avec ses seuils. Utilisez-la pour savoir que la machine qui fait votre supervision est elle-même saine — une sonde saturée remonte de fausses latences pour tout ce qu’elle exécute.

Choisir un type

Une échelle pratique, du moins coûteux au plus coûteux :

1. Ping — l’hôte est-il seulement là ?
2. TCP / UDP — quelque chose écoute-t-il sur le port ?
3. DNS — le nom se résout-il toujours ?
4. URL — la page répond-elle, vite, avec le bon contenu ?
5. API — le point d’accès renvoie-t-il les bonnes valeurs ?
6. Base de données — les données derrière sont-elles correctes et fraîches ?
7. EUM — un vrai utilisateur peut-il effectivement mener le parcours à bien ?

Commencez par le haut et ajoutez les barreaux là où la réponse compte. Chaque couche resserre l’endroit où vit la panne, et c’est ce qui transforme une alerte en diagnostic.

Voir aussi

• Tester un moniteur — exécuter n’importe quel contrôle en direct avant de l’enregistrer
• Opérations sur les moniteurs — créer, exécuter, modifier et maintenir les moniteurs
• Composant Moniteur en détail — planification, concurrence et stockage
• Configuration du moniteur — tous les champs, y compris le format stocké de patterns
• Évaluation SNMP et WMI — opérateurs, suggestions, explorateurs et modèles
• Moniteur EUM — parcours navigateur, TOTP et intégration coffre-fort
• Comment fonctionnent les seuils — modèle de gravité et calcul du statut

Traductions

• en: Monitor types