Fonctionnement

Trois composants interviennent : l’Integrateur enregistre chaque verification dans InfluxDB, le service de prediction apprend le comportement de chaque moniteur a partir de cet historique, et le Webserver demande les previsions, en deduit un statut prevu et decide quand alerter.

Les composants

 Sonde ──verification──▶ Integrateur ──▶ InfluxDB ◀──lit── Service de prediction
                             ▲                                  ▲
                             │ alertes predictives              │ HTTPS signe (prevision, entrainement)
                             └───────────────── Webserver ──────┘

Une prevision, etape par etape

1. Le Webserver lit les definitions des moniteurs sur chaque sonde et garde celles dont la prediction est activee (rafraichi toutes les 10 minutes, ou aussitot avec Lancer les predictions maintenant).
2. Au rythme propre du moniteur (chaque minute pour un moniteur a 1 minute), il demande une prevision au service.
3. Le service lit les dernieres verifications du moniteur dans InfluxDB, sans les verifications en echec (ERROR, TIMEOUT, UNKNOWN, CONFIG, DOWNTIME) : un timeout ne dit rien du temps de reponse.
4. Le modele prevoit les prochaines verifications : 5 par defaut, ou le nombre de previsions propre au moniteur (50 au plus), avec un intervalle a 80 % et a 95 % autour d’elles (voir Intervalles de prevision).
5. Le service donne aussi le risque de depassement : pour chaque seuil du moniteur, la probabilite qu’une de ces prochaines verifications l’atteigne. Le niveau le plus haut dont le risque passe le seuil de declenchement propre au moniteur est le statut prevu (OK, MINOR, MAJOR ou CRITICAL). Quand l’historique du moniteur n’annonce pas ses depassements, il n’y a ni statut prevu ni alerte de prevision : voir Risque de depassement.
6. Le service note aussi la derniere verification : il la compare a ce que le modele attendait pour elle, d’apres les verifications precedentes. Trois ecarts-types ou plus de l’erreur habituelle du modele : c’est une anomalie.
7. La reponse indique quand la verification la plus recente a eu lieu. Si elle date de plus de trois periodes du moniteur (15 minutes au moins), la prevision n’est pas a jour : elle n’a pas de statut prevu et ne declenche ni ne leve aucune alerte (voir Fraicheur des donnees).

Le resultat est enregistre et affiche dans le tableau Previsions et, avec un graphique, dans l’onglet Prediction du moniteur. Le statut du moniteur, ses evenements, ses rapports et son SLA ne sont jamais modifies par une prevision.

Le modele

Chaque moniteur sur chaque sonde a son propre modele, car un moniteur se comporte differemment selon l’endroit d’ou il est verifie.

Pourquoi une mediane et pas un reseau de neurones

Les versions precedentes utilisaient un reseau de neurones (convolution + couches LSTM). Il a ete compare a des previsions statistiques simples sur l’historique reel des temps de reponse de moniteurs de tous types (API, URL, BD, DNS, ping, TCP, WebSocket) :

Sur ces moniteurs, le reseau de neurones n’a jamais ete plus precis que la mediane. Sur un ensemble plus large de 65 moniteurs, la mediane a fait mieux que la repetition de la derniere verification sur 98 % d’entre eux (erreur 0,73).

Mesure a nouveau en novembre 2026 sur un autre ensemble, 81 moniteurs d’une installation de demonstration (60 jours de verifications, chaque statistique ajustee sur la premiere moitie de l’historique d’un moniteur et jugee sur la seconde uniquement) : erreur 0,73 de la repetition de la derniere verification (mediane sur les moniteurs), meilleure sur 97,5 % d’entre eux ; la moyenne des 60 dernieres verifications obtient 0,90.

Un temps de reponse est surtout du bruit autour d’un niveau qui change de temps en temps : un reseau de neurones a peu de motifs a apprendre, et la mediane est la prevision qui reagit le moins au bruit.

Ce que detecte la detection d’anomalies

Une anomalie est une verification a trois ecarts-types ou plus de ce que le modele attendait. Dans la mesure de novembre 2026, 3,4 % des verifications ordinaires ont ete signalees (mediane sur les moniteurs), et un pic isole de +50 % du niveau du moniteur l’a ete 45 % du temps : les grands pics sont detectes, les pics moderes souvent non. Une alerte d’anomalie demande deux previsions consecutives signalees : une verification lente isolee n’alerte personne.

Le reseau de neurones reste disponible : PREDICTION_ENGINE=lstm sur le service de prediction (voir Configuration). Chaque modele garde le moteur avec lequel il a ete entraine jusqu’a son prochain entrainement. Un modele LSTM n’a ni risque de depassement ni intervalles de prevision : son statut prevu compare les valeurs prevues aux seuils.

Intervalles de prevision

La mediane est une valeur unique. L’ecart possible des verifications autour d’elle est montre par deux intervalles :

Ils viennent des erreurs propres de la mediane sur le moniteur (jusqu’a 2 000 verifications recentes), mesurees separement pour chaque pas : ils s’elargissent avec l’horizon et ne sont pas symetriques. Un temps de reponse monte brutalement bien plus souvent qu’il ne baisse : la borne haute est en general bien plus loin de la prevision que la borne basse.

A l’entrainement, le service verifie aussi honnetement ces intervalles : calcules sur les 70 % les plus anciens de ces erreurs, combien des 30 % les plus recentes y sont tombees ? Cette part est affichee dans l’onglet Prediction du moniteur (l’intervalle a 80 % a contenu 81 % des controles recents). Sous 70 %, l’onglet signale que le comportement du moniteur a change et que l’intervalle est trop etroit jusqu’au prochain entrainement.

Dans la mesure de novembre 2026 sur 81 moniteurs, l’intervalle a 80 % a contenu 77 % des verifications suivantes (mediane ; 64 % ou moins pour un moniteur sur dix) et celui a 95 % 91 %. Lisez-les comme un ordre de grandeur de la dispersion habituelle, pas comme une garantie : un moniteur dont le comportement change les rend trop etroits jusqu’a son reentrainement (chaque semaine par defaut).

Une precision verifiable

L’onglet Prediction du moniteur donne deux mesures, toutes deux face a la prevision la plus simple, la prochaine verification ressemblera a la derniere :

Fraicheur des donnees

Une prevision n’est pas plus a jour que les verifications dont elle est tiree. Si la verification la plus recente trouvee par le service date de plus de trois periodes du moniteur (15 minutes au moins), le Webserver marque la prevision pas a jour : Aucun nouveau controle depuis …. Elle n’a alors pas de statut prevu, ne declenche aucune alerte et n’en leve aucune. Cela arrive quand le moniteur est arrete, que la sonde est hors service ou que l’Integrateur n’ecrit plus dans InfluxDB.

Risque de depassement

Une prevision plate ne franchit presque jamais un seuil avant les verifications elles-memes. Sur un historique reel, comparer les valeurs prevues aux seuils n’a annonce qu’environ 1 % des depassements avant leur debut. Le statut prevu vient donc d’un risque de depassement.

A l’entrainement, le service parcourt l’historique du moniteur a chaque instant ou il etait encore sous son seuil le plus bas, et apprend comment la probabilite d’un depassement dans les prochaines verifications depend de :

• la position de la mediane recente et de la derniere verification par rapport au seuil,
• la plus haute des 5 dernieres verifications,
• la frequence a laquelle le seuil a ete atteint sur les 60 et les 600 dernieres verifications,
• la variabilite des verifications.

Il rejoue ensuite ce calcul sur les 30 % les plus recents de l’historique, dont il n’a pas appris, et ne garde les alertes de prevision que si, sur cette periode :

Le niveau de risque est choisi la ou les avertissements etaient justes au moins 60 % du temps (le plancher plus 10 points), sur une moitie de la periode rejouee, puis compte sur l’autre moitie, et inversement. Choisir et juger sur les memes verifications flatte le resultat : sur des series de test, un niveau choisi au plancher de 50 % ne s’est revele juste que 33 % a 40 % du temps sur les verifications suivantes. La precision et la part de depassements annonces affichees par le tableau des previsions sont celles de ce controle croise.

Ce niveau de risque devient le seuil de declenchement du moniteur : un niveau est prevu quand le risque de l’atteindre le depasse. Le tableau des previsions affiche le risque ; le survol indique la part d’avertissements justes sur l’historique de ce moniteur.

A quoi s’attendre

Mesure avec le service 1.4 sur les 65 moniteurs du banc d’essai, chacun avec son seuil a son propre 95e centile, sur un historique tenu a l’ecart de l’entrainement. Le service 1.5 juge plus strictement (ci-dessus) : attendez-vous a des alertes de prevision sur moins de moniteurs, avec des chiffres de precision plus fiables. Les chiffres de la version 1.5 n’ont pas ete mesures a nouveau sur de longs historiques reels : l’installation de demonstration de novembre 2026 n’avait que quelques semaines de verifications par moniteur, trop peu pour juger un risque de depassement.

Sur les autres moniteurs, les depassements sont arrives sans signe avant-coureur dans les temps de reponse : panne soudaine, dependance, reseau. Les alertes de prevision restent desactivees pour eux et le tableau des previsions en donne la raison ; la detection d’anomalies, qui reagit a la verification elle-meme, continue de fonctionner.

Un depassement prevu est un risque, pas une certitude : environ un avertissement sur deux est suivi d’un depassement dans l’horizon de prevision.

Entrainement

Rien a lancer a la main. Le Webserver demande un entrainement au service :

Le service entraine un modele a la fois, dans un processus separe, et ne remplace un modele que lorsque le nouveau est complet : les previsions continuent avec l’ancien pendant ce temps. Le modele precedent est conserve dans le dossier previous du service.

Avec Entrainement manuel uniquement, le Webserver ne demande jamais d’entrainement de lui-meme ; utilisez Entrainer maintenant.

Alertes predictives

Quand Envoyer des alertes predictives est active, le Webserver suit le statut prevu et l’indicateur d’anomalie de chaque moniteur :

• Une alerte part quand un nouvel etat est vu sur deux previsions consecutives. Une prevision isolee n’alerte personne.
• Un retour a la normale part quand l’etat redevient OK, selon la meme regle.
• Les alertes de prevision et d’anomalie sont suivies separement. Alerter sur choisit lesquelles partent, et le reglage Alertes de prevision de chaque moniteur (onglet Prediction du moniteur) peut le remplacer pour les alertes de prevision (voir Configuration).
• Les alertes de prevision ne partent que pour les moniteurs dont le risque de depassement s’est montre fiable sur leur historique. Le message donne le risque et la part d’avertissements justes sur ce moniteur. Quand les alertes de prevision d’un moniteur sont suspendues (seuils modifies), une alerte de prevision en cours est levee.
• Les alertes utilisent les canaux au changement de statut du moniteur (email, Slack, Teams, PagerDuty, script), distribuees par les Integrateurs. Un moniteur sans canal de ce type ne recoit pas d’alerte predictive.
• Elles sont clairement signalees : le moniteur est nomme <moniteur> (forecast) et le message commence par Forecast: ou Anomaly:. Elles ont leur propre incident PagerDuty, distinct de celui du moniteur.
• L’Integrateur ne fait que notifier : une alerte predictive n’atteint jamais InfluxDB, les connecteurs ITSM ni la page Evenements.

Securite

Haute disponibilite

Dans un cluster de Webservers, seul le Webserver actif lance les previsions, les demandes d’entrainement et les alertes. La cle de signature est partagee par tous les noeuds : une bascule ne demande aucun changement sur le service de prediction.

Traductions

• en: How it works