Monitor

Le Monitor est une sonde de surveillance distribuee qui execute des verifications, collecte des donnees de performance et transmet les resultats. Deployez plusieurs instances a travers votre infrastructure pour une surveillance distribuee.

Vue d’ensemble

Gestion du service

Commandes CLI

# Install as service and register with the Webserver
monitor install <webserver_ip>:<port>

# Re-register with the Webserver (e.g., after IP change)
monitor register <webserver_ip>:<port>

# Migrate to a new Webserver (regenerates the certificate, re-registers)
monitor migrate <webserver_ip>:<port> <jwt_token>

# Start / Stop / Restart the service
monitor start
monitor stop
monitor restart

# Run in foreground (Docker or debugging)
monitor run

# Remove the service
monitor uninstall

# Display help
monitor help

Lors de l'install, le Monitor :

1. Cree l’arborescence des repertoires
2. Genere une paire de cles RSA et des certificats TLS
3. Envoie une demande d’auto-enregistrement au Webserver
4. Televerse son certificat TLS pour la verification mTLS

Configuration

Le fichier monitor.json se trouve dans le meme repertoire que l’executable :

{
  "name": "probe1",
  "port": "8051",
  "webserver": "192.168.1.100:8050",
  "integratorEndPoint": "",
  "location": "Paris",
  "description": "Production monitoring probe",
  "logLevel": "info",
  "concurrencyLimit": "100",
  "dataRetention": "336",
  "backupInterval": "24",
  "nbDaysBackup": "336",
  "autoThreshold": "true"
}

Parametres principaux

Configuration du navigateur (pour les moniteurs Web UI / EUM)

Seuils automatiques

Le Monitor peut calculer automatiquement les seuils de performance a partir des donnees historiques en utilisant une analyse statistique (multiplicateurs d’ecart-type) :

Une tache nocturne (02h00) recalcule les seuils via moyenne + (multiplicateur * ecart-type) sur les executions reussies des moniteurs actives uniquement. Les moniteurs Ping recoivent aussi des seuils de gigue (jitterThreshCri/Maj/Min). Voir Configuration du Monitor → Calcul automatique des seuils pour la formule complete et les conseils de reglage.

Integration Vault

Rotation des journaux

Arborescence des repertoires

<install_dir>/
├── monitor(.exe)            # Executable
├── monitor.json             # Configuration du service
├── config/
│   ├── sec/                 # Cles RSA pour JWT
│   └── ssl/                 # Certificats TLS pour mTLS
├── data/                    # Fichiers de definition des moniteurs (JSON)
├── dbs/                     # Bases de donnees cle-valeur integrees (une par type)
│   ├── exec.db              # Moniteurs Web UI / EUM
│   ├── url.db               # Moniteurs HTTP/HTTPS URL
│   ├── api.db               # Moniteurs REST API
│   ├── tcp.db               # Moniteurs TCP port
│   ├── udp.db               # Moniteurs UDP port
│   ├── ping.db              # Moniteurs ICMP ping
│   ├── nslookup.db          # Moniteurs DNS lookup
│   ├── db.db                # Moniteurs de requetes base de donnees
│   ├── sys.db               # Moniteurs de metriques systeme
│   ├── snmp.db              # Moniteurs SNMP
│   ├── wmi.db               # Moniteurs WMI (WQL)
│   ├── websocket.db         # Moniteurs WebSocket (ws/wss)
│   ├── chart.db             # Donnees de graphiques/performance
│   ├── monitor.db           # Donnees generales des moniteurs
│   ├── metrics.db           # Metriques propres a la sonde (CPU, memoire)
│   ├── host.db              # Inventaire des hotes
│   ├── device.db            # Inventaire des equipements
│   └── backup/              # Sauvegardes automatisees
├── log/                     # Fichiers journaux avec rotation
├── scripts/                 # Scripts personnalises pour les moniteurs
├── actions/                 # Scripts d'actions (notifications, remediation)
├── exec/                    # Executables specifiques a la plateforme (webdrivers)
└── export/                  # Exports de donnees

Types de moniteurs

1. Web UI / EUM (End User Monitoring)

Base de donnees : exec.db

Execute des parcours utilisateur multi-etapes a l’aide de Selenium WebDriver. Supporte les navigateurs Chrome, Firefox et Edge.

Capacites :

• Enregistrement de transactions multi-etapes (via MNS IDE ou Selenium IDE)
• Capture d’ecran a chaque etape
• Enregistrement video de l’execution complete
• Capture de fichiers HAR (HTTP Archive)
• Chronometrage individuel des transactions avec seuils
• Support TOTP (Time-based One-Time Password) pour l’authentification a deux facteurs (RFC 6238 — 6 chiffres / 30 s / SHA-1)
• Configuration de proxy
• Verification de similarite visuelle

Voir la page dediee Moniteur EUM pour la specification complete (compatibilite TOTP/Okta, integration des coffres-forts, fonctions de script).

Fonctions de script MNS IDE :

mnsStartTransaction("Login Page", 30, 5000, 3000); // name, timeout, critical_ms, major_ms
driver.findElement(By.id("username")).sendKeys("user");
driver.findElement(By.id("password")).sendKeys("pass");
driver.findElement(By.id("submit")).click();

2. HTTP/HTTPS URL

Base de donnees : url.db

Verifications HTTP GET simples avec des metriques de temps detaillees.

Metriques collectees :

• Temps de resolution DNS
• Temps de connexion TCP
• Temps de negociation TLS (avec detection de la version TLS)
• Temps de traitement serveur
• Temps de transfert du contenu
• Temps de reponse total
• Code de statut HTTP
• Taille du contenu
• Date d’expiration du certificat SSL

Fonctionnalites supplementaires :

• Evaluation du corps de la reponse par groupes de motifs nommes (correspondance de contenu ou extraction de valeur avec seuils)
• Controle de la taille de page face a une taille de corps attendue
• Validation du code de statut
• Verification et alerte d’expiration du certificat
• Auth Basic, certificats client, et support proxy (HTTP/HTTPS, authentifie, ou URL PAC)

3. REST API

Base de donnees : api.db

Surveillance complete d’endpoints API avec methodes HTTP, en-tetes et corps de requete personnalises.

Methodes supportees : GET, POST, PUT, DELETE

Fonctionnalites :

• En-tetes de requete personnalises
• Configuration du corps de la requete
• Evaluation du corps de la reponse par groupes de motifs nommes — chacun extrait une valeur et l’evalue face a ses propres seuils Mineur / Majeur / Critique
• Auth Basic et certificats client pour les endpoints en TLS mutuel
• Mesure du temps de reponse
• Validation du code de statut

4. Port TCP / UDP

Bases de donnees : tcp.db, udp.db

Verifications de connectivite sur les ports TCP ou UDP.

Metriques :

• Succes/echec de la connexion
• Temps de connexion
• Resolution de l’IP de destination

5. ICMP Ping

Base de donnees : ping.db

Requetes ICMP Echo Request/Reply pour tester l’accessibilite reseau.

Metriques :

• Latence minimale / maximale / moyenne
• Gigue (ecart-type)
• Paquets envoyes / recus / perdus
• Taux de perte de paquets

6. DNS Lookup (Nslookup)

Base de donnees : nslookup.db

Surveillance de la resolution DNS.

Metriques :

• Temps de resolution DNS
• Validation de la reponse

7. SNMP

Base de donnees : snmp.db

Interrogation SNMP pour la surveillance des equipements reseau.

Fonctionnalites :

• Support SNMP v1/v2c/v3
• Requetes OID avec expressions MIB
• Calculs de delta entre les interrogations
• Evaluation d’expressions sur les valeurs collectees

8. WMI

Base de donnees : wmi.db

Interrogation par requetes WQL sur les hotes Windows, dans un espace de noms (par defaut root\CIMV2).

Fonctionnalites :

• Valeur evaluee par operateur (number >, number <) ou expression reguliere
• Configurations d’identifiants et secrets issus d’un coffre-fort
• Verification en direct des requetes, explorateur de classes et modeles de requetes reutilisables sur les equipements WMI

9. Database Query

Base de donnees : db.db

Surveillance de la connectivite, de l’execution de requetes et du jeu de resultats sur les bases de donnees.

Bases de donnees supportees :

• MySQL
• Microsoft SQL Server (MSSQL)
• PostgreSQL
• Oracle

Metriques :

• Temps de connexion
• Temps d’execution de la requete
• Temps cote moteur (temps de verrou, temps CPU / worker, temps d’attente — selon le moteur)
• Evaluation du jeu de resultats par controles de colonnes : prelever une valeur par nom de colonne, par position (#2) ou le nombre de lignes (#rows), puis l’evaluer avec un operateur et des seuils Mineur / Majeur / Critique

Une requete sans ligne, une cellule NULL ou une ligne au-dela de la fin du resultat donnent un verdict CRITIQUE ; un selecteur de colonne introuvable ou ambigu donne une ERREUR (le controle est mal configure). Les jeux de resultats sont ramenes a une projection plafonnee — 64 colonnes, 512 caracteres par cellule, 100 lignes conservees lors d’une execution planifiee — afin qu’un SELECT * large ne puisse pas noyer la sonde.

10. System Metrics

Base de donnees : sys.db

Auto-surveillance de l’hote de la sonde.

Metriques :

• Pourcentage d’utilisation CPU
• Utilisation memoire
• Utilisation disque

11. WebSocket

Base de donnees : websocket.db

Surveille les points de terminaison ws:// et wss://, du simple controle de connectivite jusqu’a une session temps reel complete : authentification, envoi de messages, validation des reponses et mesure de la latence ping/pong.

Chaque execution planifiee constitue une session complete : la sonde ouvre la connexion, effectue son travail puis la ferme. Les compteurs tels que le nombre de reconnexions, la duree de connexion ou le debit de messages decrivent donc cette seule fenetre de controle, et non une disponibilite depuis le demarrage.

Authentification : aucune, Basic, jeton Bearer, cle API en en-tete, en-tetes personnalises, cookies.

Options de connexion : verification TLS, certificat client, surcharge SNI, proxy, sous-protocoles (Sec-WebSocket-Protocol), compression permessage-deflate et suivi des redirections pendant la negociation HTTP.

Les messages sortants peuvent etre envoyes des la connexion, apres N secondes ou periodiquement, en texte brut, JSON ou binaire — typiquement pour s’authentifier, s’abonner a un canal ou demander un battement de coeur.

Les regles de validation s’appliquent aux messages entrants : texte exact, contient, expression reguliere, JSON valide, ou expression JSONPath comparee avec eq / ne / contains / exists / gt / lt / regex. Chaque regle non optionnelle doit etre satisfaite avant l’echeance.

Une execution est saine lorsque la connexion TCP aboutit, que la negociation TLS reussit (pour wss://), que la mise a niveau HTTP renvoie 101 Switching Protocols, que l’authentification est acceptee, que les messages attendus arrivent et que la latence ping/pong reste dans son seuil.

Metriques, regroupees par famille dans un panneau dedie du rapport :

Les alertes peuvent etre declenchees sur un echec de connexion, un echec de mise a niveau, un echec d’authentification, un message attendu non recu dans les temps, une latence ping/pong superieure au seuil, un nombre de reconnexions superieur au seuil, une fermeture inattendue, une validation JSON en echec, ou un debit de messages entrants hors de ses bornes.

Planification

Chaque type de moniteur dispose de son propre planificateur cron independant (utilisant robfig/cron/v3). Cette isolation garantit qu’un type de moniteur lent ne peut pas bloquer les autres types.

Planifications predefinies

Controle de la concurrence

Un semaphore global limite le nombre d’executions simultanees de moniteurs (configurable via concurrencyLimit, valeur par defaut : 100). Chaque execution acquiert un emplacement avant de demarrer et le libere a la fin, empechant l’epuisement des ressources sur l’hote de la sonde.

Alertes

Le Monitor peut envoyer des alertes directement sans avoir besoin d’un Integrator.

Canaux de notification

Declencheurs d’alertes

Actions personnalisees

Les scripts d’action peuvent etre places dans le repertoire actions/ et configures par moniteur. Ils s’executent automatiquement en cas d’echec ou de changement de statut avec un delai d’expiration configurable.

Endpoints de l’API REST

Authentification

Gestion des moniteurs

Recuperation des donnees

Creation par type

Test en direct

Le Webserver appelle cet endpoint quand un utilisateur clique sur Test dans un formulaire de moniteur. :type est le type de moniteur (url, api, tcp, udp, ping, nslookup, db, snmp, wmi), le corps porte la definition du moniteur telle qu’elle est dans le formulaire, et wantJSON: "true" selectionne le rapport structure (kind: "monitorTestResult") plutot que la reponse texte d’une ligne heritee. Rien n’est stocke : l’execution n’ecrit aucun historique, ne change aucun statut et ne declenche aucune alerte. Voir Tester un moniteur.

Configuration

Stockage des donnees

Chaque type de moniteur stocke ses resultats dans sa propre base de donnees cle-valeur integree avec plusieurs buckets par moniteur :

Tous les horodatages sont stockes en millisecondes Unix (epoch en ms).

Les donnees sont automatiquement purgees en fonction du parametre dataRetention (valeur par defaut : 336 heures / 14 jours).

Voir aussi

• Types de moniteurs – catalogue oriente usage de tous les types, avec URL, API et base de donnees en detail
• Tester un moniteur – executer n’importe quel controle en direct depuis son formulaire avant enregistrement
• Configuration du Monitor – reference complete des parametres
• API HTTP du Monitor – documentation complete de l’API
• Operations de surveillance – guide de l’interface pour la gestion des moniteurs
• Vue d’ensemble de la plateforme – comment le Monitor s’integre dans l’architecture
• Exception lors de l’execution d’un moniteur – resolution des erreurs de moniteur

Traductions

• en: Monitor