Scénarios web, découverte réseau et cartes

Un scénario web Zabbix vérifie un site ou une application comme le ferait un utilisateur : il ouvre une ou plusieurs pages, contrôle le code de réponse et un texte attendu, mesure le temps de chargement, et alerte si une étape échoue. Ce chapitre montre comment superviser ainsi le site public de Sorbier depuis Internet, surveiller la date d'expiration de son certificat, découvrir automatiquement les machines d'un réseau et dessiner une carte qui affiche l'état des équipements.

Pourquoi tester comme l'utilisateur

Le serveur web peut répondre au ping, son agent être vert et son processus Nginx tourner, pendant que les clients voient une erreur 502 parce que l'application derrière est tombée, ou une page blanche parce que la base est pleine. L'épreuve blanche n° 2 de l'E6 SISR part exactement de ce cas : deux heures d'indisponibilité, apprises par les appels des utilisateurs, alors que Zabbix affichait tous les serveurs « disponibles ».

Un test de bout en bout traverse tout ce que traverse l'utilisateur : la résolution DNS, le pare-feu et sa redirection de port, le certificat, le serveur web, l'application, la base. S'il réussit, le service est rendu ; s'il échoue, les mesures de détail (agent, SNMP) disent où chercher.

Le point de santé d'une application

Une application bien conçue expose une adresse dédiée à la supervision, par convention /health : elle ne sert aucun utilisateur, elle répond « je vais bien » après avoir vérifié ses dépendances. Une version naïve qui répond toujours {"status":"ok"} ne prouve rien : elle répondrait la même chose base de données arrêtée. Une bonne version teste la connexion à la base (une requête minuscule), répond 200 et {"status":"ok"} si tout va bien, et 503 avec {"status":"degraded","db":"down"} sinon. L'outil de supervision n'a plus qu'à vérifier le code et le texte.

Le site de suivi des livraisons de Sorbier expose https://suivi.sorbier.example/api/health, qui vérifie la base et l'API de srv-gestion.

Créer un scénario web

Où placer le test ? Depuis srv-journaux, il vérifierait le serveur web en interne, mais pas le chemin des clients : DNS public, adresse publique 203.0.113.17, redirection de pfSense. Sorbier a une meilleure option : l'agence de Marseille a son propre accès Internet, et son proxy prx-mrs peut tester le site depuis l'extérieur.

1. Data collection > Hosts > Create host : Host name site-public, Visible name « Site de suivi (vu d'Internet) », groupe Services web, aucune interface (le test part du proxy lui-même), Monitored by Proxy prx-mrs. Ajoute le tag service: suivi.
2. Dans la ligne de l'hôte, colonne Web, bouton Create web scenario. Onglet Scenario : Name Suivi des livraisons, Update interval 1m, Attempts 2 (une seconde tentative avant de déclarer l'échec d'une étape).
3. Onglet Steps, bouton Add, une étape par page :

4. Onglet Authentication : coche SSL verify peer et SSL verify host. Par défaut, le scénario ne vérifie pas le certificat ; ici on veut qu'un certificat expiré ou qui ne correspond pas au nom fasse échouer le test, comme il ferait fuir un client.
5. Enregistre. Zabbix crée tout seul les éléments du scénario :

6. Crée les déclencheurs sur l'hôte site-public :

last(/site-public/web.test.fail[Suivi des livraisons])<>0
avg(/site-public/web.test.time[Suivi des livraisons,Accueil,resp],5m)>3

Le premier (gravité High, nom « Site de suivi injoignable depuis Internet (étape {ITEM.LASTVALUE1} en échec) », puisque l'élément vaut le numéro de l'étape qui échoue) signale la panne ; le message d'erreur se lit dans l'élément web.test.error, affiché dans le détail du problème ; le second (Warning), une lenteur durable. Mets-leur le tag service: suivi : c'est lui que le SLA du chapitre 2 utilise.

Les résultats sont dans Monitoring > Hosts, lien Web de l'hôte : chaque étape, son temps, son code, et le graphique des temps de réponse.

Surveiller les certificats

Un certificat expiré coupe un service aussi sûrement qu'une panne, et c'est un incident totalement prévisible. Depuis 2026, les certificats publics ont une durée de vie de 200 jours au plus, et elle va encore baisser : le renouvellement doit être automatisé, et sa réussite surveillée.

Le modèle Website certificate by Zabbix agent 2 lit le certificat d'un site avec le greffon WebCertificate de l'agent 2 (clé web.certificate.get[nom,port,ip]). Il s'utilise ainsi :

1. Crée un hôte cert-suivi avec une interface Agent qui désigne l'agent 2 qui fera le test : celui de srv-journaux, à l'adresse 127.0.0.1.
2. Lie le modèle, puis renseigne les macros : {$CERT.WEBSITE.HOSTNAME} = suivi.sorbier.example, {$CERT.WEBSITE.PORT} = 443, et {$CERT.EXPIRY.WARN} = 30 (la valeur par défaut, 7 jours, laisse trop peu de temps pour réagir si le renouvellement automatique a échoué).
3. Le modèle fournit trois déclencheurs : certificat invalide (expiré ou émis pour un autre nom, High), certificat qui expire bientôt ((last(…/cert.not_after) - now()) / 86400 < {$CERT.EXPIRY.WARN}, Warning), empreinte qui a changé (Information, pour repérer un remplacement inattendu).

Fais de même pour l'interface web de Zabbix, de Proxmox VE, de GLPI, et pour les certificats internes émis par l'autorité de l'annuaire.

Découvrir le réseau automatiquement

La découverte réseau (network discovery) balaie une plage d'adresses à intervalle régulier et note ce qui répond : un ping, un agent Zabbix, un agent SNMP, un port. Combinée à une action de découverte, elle peut créer les hôtes toute seule. C'est différent de la découverte de bas niveau du chapitre 5, qui découvre les disques ou les ports d'un hôte déjà connu.

Data collection > Discovery, bouton Create discovery rule :

Les résultats s'affichent dans Monitoring > Discovery : chaque adresse, les services trouvés, depuis quand. Puis Alerts > Actions > Discovery actions, Create action :

• conditions : Discovery rule = Serveurs Lyon (VLAN 20), Service type = Zabbix agent, Received value contains srv- ;
• opérations : Add host, Add to host groups Découverts, Link templates Linux by Zabbix agent.

Pour les équipements, une seconde règle sur le VLAN 99 utilise un contrôle SNMPv3 agent (OID 1.3.6.1.2.1.1.5.0, le nom de l'équipement) avec les macros SNMPv3 globales, et une action qui lie Cisco IOS by SNMP.

Dessiner une carte réseau

Une carte (map) montre l'infrastructure en un coup d'œil : chaque équipement prend la couleur de son problème le plus grave, chaque lien peut changer de couleur quand il sature ou tombe. C'est l'écran que l'on affiche dans le bureau du service informatique.

1. Monitoring > Maps, bouton Create map : Name « Siège de Lyon », dimensions (1 200 × 800 par exemple), Icon highlight coché (un halo de couleur autour des éléments en problème), et la façon d'afficher les problèmes sous chaque élément.
2. Ouvre la carte, bouton Edit map. Map element > Add, puis pour chaque élément : Type Host, l'hôte (pfsense, SW-ETAGE1, srv-ad…), une icône, une étiquette avec des macros ({HOST.NAME} et {HOST.CONN} pour l'adresse).
3. Pour un lien, sélectionne deux éléments (touche Ctrl), puis Link > Add. Dans les propriétés du lien, Link indicators : ajoute le déclencheur Link down du port montant (l'interface Gi1/0/48 de SW-ETAGE1, créée par la découverte du modèle), couleur rouge, trait en gras. Le lien changera de couleur avec ce déclencheur.
4. Un élément de type Map renvoie vers une autre carte : une carte « Sorbier » avec trois sites, et un clic sur « Marseille » ouvre la carte de l'agence. Un élément de type Host group résume tout un groupe.
5. Enregistre (Update). La carte s'ajoute aussi à un tableau de bord par le widget Map.

Exercices