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.
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.

Le resultat est enregistre et affiche dans le tableau Previsions. 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), et a detecte 94 % des pics anormaux pour 2,8 % de fausses alertes.

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.

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 pas de risque de depassement : son statut prevu compare les valeurs prevues aux seuils.

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 :

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 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 :

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