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

Moniteur WebSocket

Le seul type qui maintient une connexion ouverte. Un moniteur URL prouve qu’un point d’accès répond une fois ; un moniteur WebSocket prouve qu’un flux est vivant — que la mise à niveau aboutit, que les bonnes trames arrivent et que les données continuent de circuler.

Chaque exécution planifiée constitue une session complète : connexion, mise à niveau, authentification et envoi de messages éventuels, validation des réponses, puis fermeture. Les compteurs tels que le nombre de reconnexions, la durée de connexion ou le débit de messages décrivent donc cette seule session, et non une disponibilité depuis le démarrage.

Champs de connexion

Les temporisations — le point qui piège

Quatre champs indépendants. Les confondre est la cause habituelle d’un moniteur qui alerte trop lentement ou qui remonte des compteurs de trafic vides :

La fenêtre de maintien s’ajoute par-dessus le délai de connexion plutôt qu’à l’intérieur : l’allonger ne retarde donc jamais une alerte de panne.

Sans fenêtre de maintien, la session se ferme dès que ses critères sont satisfaits — juste après la mise à niveau lorsqu’il n’y a ni message attendu ni ping. C’est suffisant pour un contrôle de connectivité, mais le panneau Trafic reste proche de zéro et les débits de messages se retrouvent divisés par une session de quelques millisecondes. Définissez une fenêtre dès que vous évaluez sur un débit de messages.

Le nombre d’essais rejoue la session entière, et pas seulement la connexion : une fenêtre de 30 s avec la valeur par défaut de 2 essais coûte jusqu’à 60 s de temps réel. La sonde borne la fenêtre pour qu’elle tienne dans l’intervalle de planification, et le formulaire vous avertit lorsque ce sera le cas.

Valider les messages

Les messages sortants sont envoyés dès la connexion, après N secondes ou périodiquement, en texte, JSON ou binaire — pour s’authentifier, s’abonner à un canal ou demander un battement de cœur.

Les règles d’attente évaluent les réponses : texte exact, contient, regexp, JSON valide, ou expression JSONPath comparée avec eq / ne / contains / exists / gt / lt / regex. Chaque règle non optionnelle doit être satisfaite avant l’échéance Réception avant, sans quoi l’exécution échoue sur une erreur de validation.

Le verdict

Une exécution est saine lorsque la connexion TCP aboutit, que TLS réussit (pour wss://), que la mise à niveau renvoie 101 Switching Protocols, que l’authentification est acceptée, que chaque règle d’attente non optionnelle est satisfaite dans les temps et que le ping/pong reste sous son seuil.

Moniteurs réseau

TCP

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-le 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.

TCP est une poignée de main : une connexion réussie prouve donc réellement que quelque chose a répondu. UDP n’en a pas, et cela change tout le contrôle — d’où un type de moniteur distinct, avec ses deux modes, ci-dessous.

UDP

UDP est sans connexion : il n’y a rien à accepter, donc rien à chronométrer. Un moniteur UDP fonctionne donc dans l’un de deux modes, et c’est ce mode qui décide de ce que son statut et son temps de réponse ont le droit de signifier. La liste déroulante Check mode du formulaire le choisit.

Champs du mode requête / réponse

Choisir autre chose que Reachability only fait apparaître le bloc de charge utile :

N’importe quelle réponse est déjà la preuve que le mode joignabilité ne peut pas donner : Any reply est donc une attente parfaitement valable — ne la resserrez que si une réponse présente mais fausse compte.

Une saisie malformée est refusée à l’enregistrement plutôt que de lever une EXCEPTION à chaque cycle ensuite : un nombre impair de chiffres hexadécimaux, un échappement invalide, une regex non compilable et un seuil non numérique sont tous rejetés par le formulaire.

Modèles de protocole

La liste Check mode propose aussi des requêtes prêtes à l’emploi. En choisir une remplit la charge utile, l’attente et — tant que le champ est encore vide — le port par défaut, puis laisse tout modifiable :

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.

Workload (Kubernetes et Docker)

Un moniteur workload surveille un Deployment, StatefulSet, DaemonSet ou CronJob Kubernetes, ou un conteneur ou service compose Docker, via l’API de la plateforme elle-même. Il appartient à un hôte de conteneurs — le cluster ou l’hôte Docker — qui porte la connexion et découvre les workloads que vous pouvez adopter.

Il répond à la question qu’un moniteur URL ne peut pas trancher : non pas « la page est-elle lente » mais « l’application tourne-t-elle avec le nombre de réplicas demandé, et sinon pourquoi » — CrashLoopBackOff, ImagePullBackOff, OOM kill, éviction, exécution de CronJob en échec. Quand l’API elle-même est injoignable ou refuse les identifiants, le statut est ERREUR, qui prime sur CRITIQUE. Voir Supervision des conteneurs pour la configuration, l’évaluation et les limites.

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 — quelque chose écoute-t-il sur le port ? (UDP, et seulement avec une charge utile — voir UDP)
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.

WebSocket sort de cette échelle. Il répond à une question qu’aucun des autres ne couvre : non pas « la requête a-t-elle abouti » mais « le flux livre-t-il toujours ». Choisissez-le lorsque ce que vous vendez est un flux temps réel — cours, télémétrie, messagerie, notifications — où une socket qui se connecte correctement puis reste muette est la panne que vos utilisateurs remarquent en premier.

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
• Supervision des conteneurs — workloads Kubernetes et Docker : configuration, évaluation et limites
• 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