Sur cette page

Tester un moniteur

Chaque formulaire de moniteur porte un bouton Test. Il exécute le contrôle tout de suite, depuis la sonde qui portera le moniteur, contre la cible réelle — et renvoie un verdict étape par étape sans rien enregistrer. Ne laissez jamais planifié un moniteur que vous n’avez pas testé au moins une fois.

Ce que fait le Test

Cliquer sur Test prend les valeurs actuellement dans le formulaire — pas celles enregistrées — et demande à la sonde sélectionnée d’exécuter le contrôle exactement comme le ferait l’exécution planifiée : même requête, mêmes identifiants, même proxy, même timeout, mêmes seuils, mêmes groupes de motifs.

Ce qu’il ne fait pas :

  • il n’écrit aucun historique — l’exécution n’apparaît ni dans les graphiques ni dans les rapports ;
  • il ne change aucun statut — la tuile du moniteur n’est pas touchée ;
  • il n’envoie aucune alerte — personne n’est notifié par un test ;
  • il n’enregistre rien — fermer le formulaire jette à la fois les valeurs et le résultat.

Le Test est donc sans danger, même répété en boucle pendant que vous affinez une expression régulière ou un seuil.

Le test s’exécute sur la sonde, pas sur le Webserver. C’est tout l’intérêt : il prouve que la cible est joignable depuis l’endroit où le moniteur tournera réellement, à travers le chemin réseau, le proxy et les certificats de cette sonde. Un test qui échoue alors que la cible répond depuis votre poste est un constat, pas un bug.

Quels types le proposent

Type Bouton Test Ce que fait le test
URL ✅ Émet la requête HTTP, contrôle le statut, la taille de page et chaque groupe de motifs
API ✅ Émet la requête avec votre méthode, vos en-têtes et votre corps, puis contrôle chaque groupe de motifs
Base de données ✅ Se connecte, exécute la requête, présente un aperçu du jeu de résultats et évalue chaque contrôle de colonne
TCP / UDP ✅ Compose hôte:port avec votre timeout, remonte le temps de connexion
Ping ✅ Envoie le nombre de paquets configuré, remonte latence, gigue et taux de perte
DNS ✅ Résout le nom, remonte le temps de résolution et les adresses résolues
SNMP / WMI ✅ Test par ligne, plus un ⚡ Tout tester dans l’en-tête du panneau — voir Évaluation SNMP et WMI
EUM / Web UI — Utilisez plutôt Exécuter en mode navigateur, qui montre le parcours en direct
Système — Lit la machine de la sonde, il n’y a pas de cible

Le Test est disponible sur le formulaire Ajout, sur le formulaire Détails (édition), et en lecture seule sur le formulaire Vue.

Choisir la sonde

Le test doit savoir sur quelle sonde s’exécuter :

  • sur un formulaire d'Ajout, il utilise la première sonde de la sélection Pousser vers les sondes ;
  • sur Vue / Détails, il utilise la sonde à laquelle le moniteur est déjà affecté.

Si aucune sonde n’est sélectionnée, le test refuse de s’exécuter et le signale. Sélectionnez-en une d’abord.

Lire le panneau de résultat

Le panneau s’ouvre sous le champ cible. Il comporte trois parties, de haut en bas.

1. La bannière globale

Une ligne portant le statut le plus grave trouvé parmi tous les contrôles effectués :

✅ Test réussi — statut OK   |   ⚠ Résultat du test : MAJEUR

2. Une ligne par contrôle

Chaque contrôle effectué obtient sa propre ligne, avec une pastille de gravité, un libellé et son détail. Les lignes affichées dépendent du type :

Ligne Apparaît pour Affiche
Requête URL, API HTTP 200 · 143 ms · 12,4 Ko · application/json, ou l’erreur de connexion
Contrôle TCP, UDP, Ping, DNS Le résumé en une ligne — temps de connexion, réponses et latence moyenne, nom résolu
Temps de réponse tous Le temps mesuré face aux seuils Mineur / Majeur / Critique du formulaire, avec rappel des seuils en cas de dépassement
Jeu de résultats Base de données 142 lignes × 6 colonnes, avec une grille d’aperçu dépliable
Taille de page URL La taille du corps face à la règle configurée, ou non configuré
Motif : <nom> URL, API, Base de données Une ligne par groupe de motifs ou contrôle de colonne : ce qu’il a capturé et comment cela a été évalué
Seuil du résultat URL, API, Base de données L’agrégat — le plus grave de tous les groupes

3. La réponse brute

Une section dépliable Réponse brute contient exactement ce qui est revenu, avec sa taille et un marqueur tronqué si le corps était trop volumineux pour être renvoyé en entier. Le JSON est mis en forme et coloré syntaxiquement, ce qui permet de lire la charge utile et de choisir le champ à évaluer.

Ping et DNS y placent aussi leur détail — meilleur/pire/moyen, gigue et taux de perte pour Ping ; les adresses résolues pour DNS. Les moniteurs de base de données y affichent les temps côté moteur (temps de verrou, temps CPU/worker).

Pastilles de gravité

Pastille Signification
OK Le contrôle est passé
SKIPPED Non configuré, ou groupe désactivé — il ne contribue pas au résultat
MINEUR / MAJEUR / CRITIQUE Un seuil a été franchi. C’est un verdict sur la cible, calculé correctement
ERREUR Le contrôle lui-même n’a pas pu être évalué — expression régulière invalide, colonne introuvable, cible injoignable
MAJEUR n’est pas un test raté. Si vos seuils disent que 2 secondes est majeur et que le point d’accès a répondu en 2,4 secondes, le test a parfaitement fonctionné : il vous a dit la vérité. Mugnsoft fait aussi la distinction dans la notification — un verdict de seuil remonte le statut calculé, tandis que « Test terminé avec des problèmes » signifie que quelque chose a empêché l’évaluation du contrôle.

URL & API : du test aux groupes de motifs

La façon la plus rapide de construire des contrôles de contenu est de laisser le point d’accès les remplir :

  1. Renseignez l’URL (et, pour une API, la méthode, les en-têtes et le corps).
  2. Cliquez sur Test. La réponse brute revient.
  3. Cliquez sur Suggérer des groupes de motifs. Mugnsoft inspecte la réponse réelle — objets et tableaux JSON, paires clé : valeur en texte brut, balises <tag>valeur</tag> — et propose un nom, une expression régulière, un index de correspondance et un opérateur pour chaque valeur trouvée, avec un aperçu de ce que chacune capturerait.
  4. Décochez ce dont vous n’avez pas besoin, ajustez les noms, puis Appliquer la sélection. Les groupes arrivent dans la grille avec des seuils vides à renseigner.
  5. Cliquez de nouveau sur Test pour confirmer que chaque groupe capture et évalue bien ce que vous attendez.

Un champ nombre maximum de suggestions à côté du bouton limite le nombre de propositions (50 par défaut, jusqu’à 200).

N’appliquez que les groupes sur lesquels vous agirez vraiment. Chaque groupe appliqué est réévalué sur l’intégralité du corps de la réponse à chaque contrôle, et stocke sa propre série d’historique. Dix groupes bien choisis valent mieux que cent groupes ramassés — pour la collecte massive de métriques, utilisez une chaîne de métriques dédiée, pas un moniteur.

Base de données : l’aperçu du jeu de résultats

Un test de base de données fait plus que chronométrer la requête. Il renvoie un aperçu plafonné de ce que la requête a produit — jusqu’à 20 lignes et 64 colonnes, chaque cellule tronquée à 512 caractères — et cet aperçu remplit deux rôles :

  • Vous voyez la forme de vos données avant d’écrire le moindre contrôle : noms de colonnes, types, premières lignes.
  • Les noms de colonnes deviennent des suggestions d’auto-complétion dans chaque cellule colonne de la grille des contrôles, aux côtés du sélecteur #rows.

L’aperçu n’existe que dans la réponse du test. Il n’est jamais stocké, jamais tracé, et ne quitte jamais le formulaire.

La boucle recommandée est donc :

  1. Saisissez les informations de connexion et la requête, cliquez sur Test, lisez le jeu de résultats.
  2. Ajoutez un contrôle de colonne, choisissez la colonne dans l’auto-complétion, sélectionnez l’opérateur.
  3. Cliquez de nouveau sur Test — chaque contrôle apparaît alors sur sa propre ligne avec la valeur capturée et son évaluation.
  4. Ajustez les seuils jusqu’à ce que le verdict corresponde à ce que vous considérez comme sain, puis enregistrez.

Un contrôle qui remonte ERREUR — column 'loaded_at' not in result set, ou column 'id' is ambiguous, appears more than once — select it by position (#2 or #5) — vous dit de corriger le contrôle. Un contrôle qui remonte CRITIQUE — query returned no rows, value is NULL — vous parle de vos données.

Quand un test échoue

Symptôme Cause probable
unreachable — … La sonde ne joint pas la cible : pare-feu, DNS, proxy, ou le service est réellement tombé
Select a probe first to run the test Aucune sonde choisie sur le formulaire
Failed — could not reach probe … to run the test La sonde est hors ligne ou injoignable depuis le Webserver — voir problèmes de communication
HTTP 401 / 403 sur la ligne Requête Identifiants, en-tête ou certificat client erronés
no match found in the response sur un groupe de valeur L’expression régulière ne correspond pas à ce corps — lisez la réponse brute et refaites-la, ou utilisez Suggérer des groupes de motifs
content not found in the response sur une correspondance de contenu Le corps ne contient réellement pas le texte — c’est le contrôle qui fonctionne
ERREUR sur un groupe de motifs L’expression régulière ne compile pas, ou ne capture rien d’exploitable
failed to execute the query Connexion refusée, identifiants erronés, erreur SQL, ou timeout trop court
Un résultat en texte brut sur une ligne au lieu du panneau La sonde est antérieure au rapport de test structuré — mettez la sonde à jour pour obtenir le panneau complet

Habitudes à garder

  • Tester avant chaque enregistrement, à la création comme à chaque modification. Un moniteur correct le mois dernier ne l’est pas forcément après un changement du point d’accès.
  • Tester après avoir changé de sonde. La joignabilité est une propriété de la sonde, pas de la cible.
  • Tester après un changement de seuil pour voir le nouveau verdict immédiatement plutôt que d’attendre la prochaine exécution planifiée.
  • Utiliser la réponse brute comme documentation — c’est le moyen le plus rapide de voir ce qu’un point d’accès renvoie réellement aujourd’hui.

Voir aussi

Traductions

Types de moniteurs