Tutoriel : votre premiere prevision

Ce tutoriel mene un moniteur URL de rien jusqu’a une prevision, un statut prevu et une alerte. Comptez une vingtaine de minutes, dont l’essentiel a attendre la fin du premier entrainement.

Avant de commencer

Les commandes utilisent ces valeurs d’exemple. Remplacez-les par les votres.

Etape 1 : configurer le service de prediction

Le service tourne en conteneur Docker, ou a partir des binaires sous Linux ou Windows. Choisissez le votre : le choix vaut pour toute la page.

Le service lit l’historique des moniteurs avec sa propre connexion InfluxDB : le Webserver ne lui envoie jamais d’identifiants.

# InfluxDB dans lequel ecrit l'Integrateur
INFLUXDB_URL=http://influxdb.example.com:8086
INFLUXDB_TOKEN=<jeton InfluxDB en lecture seule>
INFLUXDB_ORG=mugnsoft
INFLUXDB_BUCKET=monitoring
PREDICTION_TSDB=influxdb            # influxdb3 pour InfluxDB v3 (avec INFLUXDB_DATABASE)

# Seules les requetes signees par votre Webserver sont acceptees (cle copiee a l'etape 3)
PREDICTION_JWT_PUBLIC_KEY=/sec/webserver_prediction.pub
PREDICTION_REQUIRE_JWT=true

# TLS
PREDICTION_SSL_KEY=/sec/private.key
PREDICTION_SSL_CERT=/sec/certificate.crt

# InfluxDB dans lequel ecrit l'Integrateur
INFLUXDB_URL=http://influxdb.example.com:8086
INFLUXDB_TOKEN=<jeton InfluxDB en lecture seule>
INFLUXDB_ORG=mugnsoft
INFLUXDB_BUCKET=monitoring
PREDICTION_TSDB=influxdb            # influxdb3 pour InfluxDB v3 (avec INFLUXDB_DATABASE)

# Seules les requetes signees par votre Webserver sont acceptees (cle copiee a l'etape 3)
PREDICTION_JWT_PUBLIC_KEY=sec/webserver_prediction.pub
PREDICTION_REQUIRE_JWT=true

# TLS
PREDICTION_SSL_KEY=sec/private.key
PREDICTION_SSL_CERT=sec/certificate.crt

# Modeles et etat de l'entrainement
PREDICTION_MODEL_DIR=models

# InfluxDB dans lequel ecrit l'Integrateur
INFLUXDB_URL=http://influxdb.example.com:8086
INFLUXDB_TOKEN=<jeton InfluxDB en lecture seule>
INFLUXDB_ORG=mugnsoft
INFLUXDB_BUCKET=monitoring
PREDICTION_TSDB=influxdb            # influxdb3 pour InfluxDB v3 (avec INFLUXDB_DATABASE)

# Seules les requetes signees par votre Webserver sont acceptees (cle copiee a l'etape 3)
PREDICTION_JWT_PUBLIC_KEY=sec/webserver_prediction.pub
PREDICTION_REQUIRE_JWT=true

# TLS
PREDICTION_SSL_KEY=sec/private.key
PREDICTION_SSL_CERT=sec/certificate.crt

# Modeles et etat de l'entrainement
PREDICTION_MODEL_DIR=models

Etape 2 : demarrer le service

docker run -d --name prediction --restart unless-stopped -p 8000:8000 \
  --env-file prediction.env \
  -v prediction-models:/models \
  -v "$PWD/sec":/sec:ro \
  mugnsoft/prediction:1.4

sudo tar -xzf mugnsoft-prediction-1.4.0.linux-amd64.tar.gz -C /opt/mugnsoft/prediction
sudo useradd --system --home-dir /opt/mugnsoft/prediction --shell /usr/sbin/nologin mugnsoft-prediction
sudo chown -R mugnsoft-prediction: /opt/mugnsoft/prediction
sudo chmod 600 /opt/mugnsoft/prediction/.env

cd /opt/mugnsoft/prediction
sudo -u mugnsoft-prediction ./api

sudo tee /etc/systemd/system/mugnsoft-prediction.service >/dev/null <<'EOF'
[Unit]
Description=Mugnsoft prediction service
After=network-online.target
Wants=network-online.target

[Service]
User=mugnsoft-prediction
WorkingDirectory=/opt/mugnsoft/prediction
ExecStart=/opt/mugnsoft/prediction/api
Restart=on-failure
RestartSec=10
NoNewPrivileges=true
ProtectSystem=full
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now mugnsoft-prediction

# firewalld (famille RHEL)
sudo firewall-cmd --permanent --add-port=8000/tcp && sudo firewall-cmd --reload
# ou ufw (Debian / Ubuntu)
sudo ufw allow 8000/tcp

Expand-Archive mugnsoft-prediction-1.4.0.windows-amd64.zip -DestinationPath C:\mugnsoft\prediction

cd C:\mugnsoft\prediction
.\api.exe

$dir = "C:\mugnsoft\prediction"
$action   = New-ScheduledTaskAction -Execute "$dir\api.exe" -WorkingDirectory $dir
$trigger  = New-ScheduledTaskTrigger -AtStartup
# pas de limite de 72 heures, redemarrage s'il s'arrete sur une erreur
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) `
              -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
Register-ScheduledTask -TaskName "Mugnsoft prediction" -Action $action -Trigger $trigger `
  -Settings $settings -User "NT AUTHORITY\SYSTEM" -RunLevel Highest
Start-ScheduledTask -TaskName "Mugnsoft prediction"

New-NetFirewallRule -DisplayName "Mugnsoft prediction" -Direction Inbound `
  -Protocol TCP -LocalPort 8000 -Action Allow

Verifiez qu’il repond (curl.exe dans Windows PowerShell) :

curl -k https://prediction.example.com:8000/health

"backend_configured": true signifie que le service a trouve ses parametres InfluxDB. Le fichier de cle publique n’existe pas encore : c’est l’etape suivante.

Etape 3 : relier le Webserver

1. Ouvrez Parametres, la fenetre des parametres du Webserver, onglet Analyse predictive.
2. Dans URL de l’API de prediction, saisissez https://prediction.example.com:8000.
3. Cliquez sur Recuperer le certificat. L’empreinte du certificat du service remplit le champ en dessous. Comparez-la avec le certificat present sur l’hote du service, puis gardez-la : le Webserver acceptera desormais ce certificat et aucun autre.
4. Cliquez sur Copier sous Cle de signature (publique) et enregistrez le texte dans le fichier attendu par le service (sec/webserver_prediction.pub ici). Le service relit le fichier quand il change : pas de redemarrage.
5. Cliquez sur Enregistrer les parametres de prediction. Tester la connexion se lance alors de lui-meme et coche quatre etapes : URL du service renseignee, Service joignable, Signature de ce webserver acceptee et Le service lit InfluxDB. Une etape en echec indique quoi corriger.

Le statut doit indiquer Connecte, avec la version du service et son nombre de modeles. Si Signature de ce webserver acceptee echoue, le fichier de cle publique du service est absent ou perime : refaites le point 4. Un champ modifie sans enregistrer ? L’onglet affiche Modifications non enregistrees : le test utilise toujours les parametres enregistres.

Etape 4 : choisir l’entrainement et les alertes

Plus bas dans le meme onglet :

• Reentrainer chaque modele : gardez Chaque semaine.
• Envoyer des alertes predictives : cochez-le, et gardez Alerter sur = Depassement prevu et anomalie.

Cliquez de nouveau sur Enregistrer les parametres de prediction.

Etape 5 : activer la prediction sur un moniteur

1. Ouvrez le detail du moniteur (ici shop sur probe1), onglet Prediction.
2. Activez Activer. Laissez Verifications a prevoir vide pour utiliser la valeur par defaut (5 verifications).
3. Laissez Alertes de prevision sur Par defaut : le moniteur suit alors les parametres de l’etape 4. Active ou Desactive les remplace pour ce seul moniteur.
4. Enregistrez le moniteur. L’encadre Etat de la prediction du meme onglet suit ensuite le modele puis, une fois entraine, les previsions.

C’est tout : rien a lancer a la main. En dix minutes au plus le Webserver voit le moniteur, constate qu’il n’a pas encore de modele et demande au service d’en entrainer un.

Etape 6 : suivre la premiere prevision

De retour dans Parametres > Analyse predictive, le tableau Previsions liste chaque moniteur dont la prediction est activee. Cliquez sur Lancer les predictions maintenant pour ne pas attendre. Le tableau s’actualise de lui-meme tant qu’un modele attend son entrainement, et Filtrer les moniteurs retrouve un moniteur parmi beaucoup.

La colonne Modele passe de En attente a Entrainement puis Pret, en quelques secondes par moniteur. La colonne Prevision montre alors le statut prevu et son risque de depassement : la probabilite qu’une des prochaines verifications atteigne un seuil. Le survol indique la part d’avertissements justes sur l’historique de ce moniteur. Anomalie montre le score de la derniere verification.

Ici le modele est pret, et le risque qu’une des 5 prochaines verifications atteigne le seuil MINOR est de 4 % : le statut prevu est OK. Il passe a MINOR quand ce risque depasse le niveau que l’historique de ce moniteur a montre digne d’un avertissement.

Sur certains moniteurs la ligne indique Pas d’alerte de prevision, suivi de la raison (aucun seuil defini, pas encore assez d’historique, depassements sans signe avant-coureur…). Ce n’est pas une erreur : la prevision tourne et les alertes d’anomalie fonctionnent, mais l’historique n’annonce pas assez les depassements de ce moniteur pour qu’un avertissement soit fiable. Voir Risque de depassement.

Etape 7 : recevoir une alerte predictive

Une alerte predictive part des que le meme statut prevu est vu sur deux previsions consecutives, puis de nouveau quand il disparait. Elle va sur les canaux que le moniteur utilise au changement de statut (email, Slack, Teams, PagerDuty ou script), via les Integrateurs, et elle est signalee comme une prevision :

Les messages d’alerte sont en anglais.

Les alertes de prevision ne partent que pour les moniteurs dont le risque de depassement s’est montre fiable sur leur historique ; les alertes d’anomalie partent pour tous les moniteurs.

Aucune alerte ? Verifiez que le moniteur a au moins un canal active au changement de statut, que l’Integrateur a aussi ce canal active, et que le reglage Alertes de prevision du moniteur n’est pas sur Desactive.

Ensuite

• Fonctionnement : ce que le modele apprend, quand il est reentraine, ce qui compte comme une anomalie.
• Configuration : chaque parametre, la rotation de la cle, l’API.
• Depannage.

Traductions

• en: Tutorial: your first forecast