Sur cette page

Prédictions

Les prédictions prévoient le temps de réponse futur d’un moniteur à partir de son historique récent et transforment cette prévision en statut prédit — pour voir une dégradation arriver avant qu’elle ne franchisse vos seuils.

Mugnsoft lit l’historique du temps de réponse d’un moniteur depuis InfluxDB, l’envoie à un service externe d’apprentissage automatique, puis stocke la prévision aux côtés du moniteur. La prévision est comparée aux seuils mineur / majeur / critique du moniteur pour déduire un statut prédit (OK, MINOR, MAJOR ou CRITICAL).

Prérequis

Les prédictions reposent sur deux éléments externes :

  • InfluxDB contenant l’historique du temps de réponse du moniteur (v1, v2 et v3 sont pris en charge). Voir Intégration avec InfluxDB.
  • Le moteur de prédiction — un service Python (train.py pour construire un modèle par moniteur, api.py pour servir les prévisions) que Mugnsoft appelle en HTTP.

Fonctionnement

  1. À mesure que les moniteurs s’exécutent, le Webserver interroge InfluxDB pour obtenir les 30 derniers jours du responseTime du moniteur pour la sonde concernée.
  2. Il envoie cette série au point de terminaison /predict du moteur de prédiction, en demandant un nombre de points futurs (le nombre de prédictions, 5 par défaut).
  3. Le moteur renvoie les valeurs prévues.
  4. Le Webserver prend la valeur prédite la pire (la plus haute) et la compare aux seuils du moniteur pour déduire le statut prédit.
  5. Le résultat est stocké et affiché sur le moniteur.

Les prédictions s’exécutent de manière asynchrone et ne bloquent jamais l’exécution des moniteurs. Chaque couple moniteur+sonde a un délai de refroidissement, afin qu’un moniteur très actif ne soit pas re-prédit à chaque exécution.

Un modèle doit d'abord être entraîné

Le moteur ne peut prévoir qu’un moniteur pour lequel il possède un modèle entraîné. Si aucun modèle n’existe, le résultat stocké porte une erreur model not found et une commande d’entraînement prête à l’emploi. Entraînez le modèle une fois par couple moniteur+sonde (voir Entraîner un modèle), puis les prédictions commencent à réussir.

Configurer le moteur de prédiction

Les paramètres de prédiction sont globaux et stockés dans le Webserver. Configurez-les depuis la page Paramètres (ADMIN uniquement) ou via l’API.

Paramètre Description Défaut
URL de l’API de prédiction URL de base du service Python de prédiction http://localhost:5000
Clé API de prédiction Clé API optionnelle envoyée au service (vide)
URL InfluxDB Point de terminaison InfluxDB d’où lire l’historique (requis)
Version InfluxDB Dialecte de requête : v1, v2 ou v3 v2
Org / token / bucket / database InfluxDB Connexion et authentification selon la version InfluxDB (requis)
Nombre de prédictions par défaut Nombre de points futurs à prévoir par moniteur 5

Quels champs InfluxDB s'appliquent

La version choisie détermine les champs pertinents : v1 utilise database, v2 utilise org + bucket, v3 utilise database + bucket. Le token est utilisé par v2 et v3. Mugnsoft construit automatiquement le bon dialecte (Flux pour v2, InfluxQL pour v1, SQL pour v3).

Mettre à jour les paramètres via l’API :


curl -X POST https://webserver:8050/updatePredictionSettings \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "predAPIURL": "http://predictor:5000",
    "predAPIKey": "",
    "predInfluxURL": "http://influxdb:8086",
    "predInfluxOrg": "mugnsoft",
    "predInfluxToken": "<influx-token>",
    "predInfluxBucket": "monitoring",
    "predInfluxVersion": "v2",
    "predDefaultCount": 5
  }'

Entraîner un modèle

Chaque couple moniteur+sonde nécessite son propre modèle avant de pouvoir être prévu. Le résultat de prédiction stocké pour un moniteur non entraîné inclut une commande d’entraînement pré-remplie — copiez-la et exécutez-la sur l’hôte du moteur de prédiction. La commande récupère un historique plus long (environ 280 jours) et entraîne sur 100 epochs :


python train.py \
  --token "<influx-token>" \
  --bucket "monitoring" \
  --url "http://influxdb:8086" \
  --data_name "myservice_probe1" \
  --query "<requête InfluxDB pré-remplie>" \
  --epochs 100

Le data_name est dérivé des noms du moniteur et de la sonde (en minuscules, avec espaces, /, - et . remplacés par des underscores), de sorte que chaque couple moniteur+sonde correspond à un modèle distinct.

Consulter et déclencher les prédictions

Les prédictions apparaissent sur chaque moniteur dès qu’un modèle existe et que le moteur a été joignable au moins une fois.

  • Automatiquement — à mesure que les moniteurs s’exécutent, ceux éligibles sont prévus en arrière-plan (dans la limite du délai de refroidissement).
  • À la demande — déclenchez un recalcul complet pour tous les moniteurs :

curl -X POST https://webserver:8050/runPredictions \
  -H "Authorization: Bearer $TOKEN"

Lire la dernière prévision d’un moniteur :


curl https://webserver:8050/prediction/myservice/probe1 \
  -H "Authorization: Bearer $TOKEN"

La réponse inclut les valeurs prédites, le predictedStatus déduit, la date de dernière mise à jour (lastUpdated) et — si le modèle est absent — la commande trainCmd pour corriger.

Dépannage

Symptôme Cause Solution
Le résultat affiche model not found Aucun modèle entraîné pour ce couple moniteur+sonde Exécutez la commande d’entraînement pré-remplie
Aucune prédiction n’apparaît URL InfluxDB non configurée Renseignez la connexion InfluxDB dans les paramètres de prédiction
Statut prédit toujours OK Le moniteur n’a aucun seuil mineur/majeur/critique Définissez des seuils d’alerte sur le moniteur
Prévision erronée ou vide InfluxDB contient trop peu d’historique, ou la mauvaise version/dialecte est sélectionnée Vérifiez qu’au moins 30 jours de données existent et que la version InfluxDB correspond à votre déploiement

Voir aussi

Traductions

Évaluation SNMP et WMI