La supervision est l'outil d'automatisation par excellence des OPS

C'est l'oeil et l'oreille de l'équipe informatique dans les infras.

En effet, avoir des serveurs, des dockers, des app, des fronts, des backs, des saas ... c'est bien

Mais savoir s'il fonctionne, c'est mieux. Et connaitre beaucoup ils ont arrêté de fonctionner, c'est le top.

Mais comment ça fonctionne la supervision généralement ?

Le truc de base : les sondes

Les outils de supervision sont des orchestrateurs de sondes.

C'est à dire qu'ils planifient l'exécution automatique de plusieurs scripts/programme pour vérifier l'état des éléments informatiques.

L'exemple le plus courant : l'utilisation disque d'un OS : une sonde va interroger un serveur pour savoir si son disque est plein
Et comment on fait ça ? Avec un script SSH par exemple pour Linux, avec WMI ou powershell pour Windows ...
On dit à la Supervision de le faire toutes les 5 min et de lever une alerte s'il reste 20% ou moins d'espace disponible Comme ça, l'admin peut faire le nécessaire AVANT la panne.

Donc une sonde donne plusieurs informations :
- Un code retour : OK, Warning, Critical, Unknow (en fonction des arguments passés à la sonde)
- Un texte court : qui donne quelques infos textuelles sur le dernier résultat de son exécution
- Des perf data : des métriques pour faire des graphes (on en parle plus bas)

Il existe plein de sondes sur le Net et elles sont dépendantes de ton outil de supervision Même s'il y a une habitude de les écrire en respectant les spec Nagios (outil de supervision historique)

Des exemples de sondes :
- Utilisation Disque, CPU, RAM
- Serveur Up ou Down
- Débit sur les ports d'un switch
- Page web d'un site OK (avec recherche syntaxique)
- Temps de réponse d'une APP
- Temps de latence sur le réseau
- Sur consommation de la bande passante internet
- Services Linux/Windows lancés ou arrêtés

Il y en a des milliers de différents. Donc si tu veux surveiller un truc en automatique, c'est sur que tu vas trouver
Au pire, tu peux le dev toi même.

Les alertes

C'est bien beau d'avoir des sondes qui s'exécutent fréquemment et qui testent plein de choses
Mais quand il y a une alerte ou une panne il faut pouvoir être averti

Les outils de Sup utilisent plusieurs mécanismes :
- La console web
- L'alerting

La console web est le dashboard sur lequel tu vois toutes tes sondes.
Elles sont vertes quand c'est OK
Orange en warning
Rouge en critical
Grises en unknown (généralement hein, ce sont des conventions)
Donc avec visuellement tu vois s'il y a un problème.
C'est pour ça, que tu vois souvent dans les Open Space d'OPS des grands écrans aux murs, avec plein de choses qui clignotent dessus

Inconvénient, ça demande de regarder l'écran. Sauf qu'on a autre chose à faire que de regarder un écran de sup toute la journée

Il y a donc les alertes.

Historiquement, ce sont des emails qui sont envoyés à l'équipe
Ces emails contiennent toutes les informations de l'alerte :
- Le serveur impacté
- La sonde en alerte
- Les infos de la sonde
- La date et l'heure de l'évènement ...

Mais avec l'avènement des outils de comm (slack, teams ...), on utilise de plus en plus des alertes via ces outils de com
Les alertes (comme les sondes) sont des scripts qui sont exécutés quand les conditions sont remplies
Exemple : Envoie ce message dans Slack sur tel channel quand n'importe quelle sonde passe à Critical
Donc tu peux utiliser les scripts que tu trouves sur le Net ou dev toi même

Le truc le plus fun que j'ai fait, c'est de dev une alerte qui fait sonner une Patlite et la fait clignoter dans l'Open Space.
C'était en complément du mail.

Le challenge ici, c'est de ne pas être spammé par les alertes. D'en avoir trop à traiter et donc ne plus rien faire du tout.
C'est ce que j'ai constaté en passant dans plusieurs DSI : il y a 100 alertes au rouge. Quand je pose la question "Ah ben c'est normal, y'en a trop, on traite plus"

Donc pour éviter ça, il y a une phase de rodage : régler la sensibilité des sondes, supprimer les sondes qui ne servent pas, rassembler les sondes par relations (on en parle en bas)

Investiguer

Maintenant, on a des sondes qui s'exécutent régulièrement, on est averti quand il y a potentiellement une panne.

Il faut pouvoir investiguer rapidement

Plein de sondes sont basiques : le disque est plein. Ben y'a pas à chercher. On a la cause du problème

Parfois, c'est plus complexe.

Cas réel vu : tu as 15 serveurs d'une salle qui passent tous en rouage d'un coup
Là, panique. Qu'est ce qui se passe ? Tout est cassé ?
Et tu te rends compte que dans le lot d'alerte, il y a le routeur qui est devant ces 15 serveurs qui est down.
Donc c'est normal que la sup ne puisse plus aller checker les serveurs. Donc pour lui tout est down.
En vrai, la panne ne vient que du routeur.
Mais noyé sous toutes les alertes, tu ne le vois pas forcément tout de suite.

Pour corriger ça, les outils ont la notion de relation : c'est à dire que tu peux dire qu'un équipement dépend d'un autre pour la supervision Ici on peut dire que les 15 serveurs dépendent du routeur qui est devant
Ainsi quand le routeur tombe en panne, la sup sait que toutes les dépendances ne peuvent plus être supervisées.
Donc il met toutes les sondes en attente sauf celles de ton routeur.
Donc au lieu d'avoir plein d'alertes, tu n'as que celle qui t'intéresse : ton routeur
Dans les outils récents, il te dit même : ok ton routeur est down et voila tout ce que ça impact. Donc tu ferais bien de te grouiller.

Autre cas complexe :
Tu as un cluster de BDD central (2 BDD par exemple)
Plusieurs app différentes utilisent ce cluster BDD (si si ça existe dans les services informatiques)
Donc quand ton cluster tombe, toutes tes app ne fonctionnent plus : ok, on retombe dans la situation du haut
Mais, si une seule BDD tombe, ton cluster fonctionne toujours. Mais si on utilise les relations vues plus haut, la sup va arrêter toutes les sondes des APP car une dépendance est tombée. Or dans les faits tout fonctionne encore.
C'est là qu'une nouvelle notion arrive : les business rule
Ce sont des relations plus évoluées
Avec la relation tu dis : si lui il tombe, moi je marche plus (c'est du 1:1)
Avec une business rule tu peux faire des trucs plus complets :
Pour que mon Site web soit considéré comme UP :
- Il faut qu'il y a ait 1 firewall sur 2 qui fonctionne
- ET qu'il y a 3 Front toujours allumés
- ET qu'une BDD sur deux soit UP
Si ça c'est rempli, mon app est ok. Sinon, alerte.

Avec ça, tu peux dessiner des arbres de dépendances intéressantes dans ton outil de supervision
Toujours dans le but de n'être averti que quand c'est utile
Autre effet de top :
Dans ce cas, tu peux dire, même si ton cluster est UP mais qu'une BDD est down, d'avertir la team BDD
Et seulement quand le cluster tout en entier est down d'avertir toute la terre pour aider à remettre en état de marche.
Donc tu veux jouer sur quand on notifie qui.

Dernier point, les sondes remontent des métriques qui permettent aux outils de faire des graphes.
Par exemple pour le disque, tu peux voir graphiquement l'espace utilisé au fil du temps.
Ca permet d'investiguer rapidement : est-ce qu'il y a eu un pic qui a saturé le disque d'un coup ? ou bien un remplissage continuel qui a fini pour atteindre le seuil ?
Cas réel vu : un pic = un utilisateur qui a fait une connerie et uploadé de gros volumes sur le disque
Une augmentation progressive = généralement des logs qui grandissent sans purge automatique

Donc investigation facilitée.

Tout configurer

On a un outil maintenant qui nous permet d'éviter les pannes (ou au mieux de les détecter assez précisément)

Quand tu as 4 serveurs et un firewall, c'est hyper simple de tout configurer à la main dans ton outil (de faire les dépendances et tout)

Mais dans un gros SI, avec du On premise, du cloud, des dockers dynamiques, des switchs, routeurs, des bâtiments distants...
Ca devient vite la loose de tout faire à la main

Les outils intègrent de l'auto discovery. Ca utilise les techno standards pour scanner tes réseaux (avec les bons credentials bien entendu)
Ca marche plutôt bien, et ça fait les dépendances pour toi. On va dire que ça configure 90% de tout ton parc pour toi.
Il te reste les 10% restant et les quelques business rules importantes.

Voilà, il y a encore beaucoup de choses à dire sur la supervision.
Mais là on a une bonne introduction