Superviser le réseau d'une PME avec Zabbix et Grafana
Une panne de switch n'était connue que lorsqu'un utilisateur la signalait : j'ai déployé Zabbix et Grafana pour suivre en continu les trois switches de l'entreprise et prévenir par e-mail.
En bref
Les trois switches de la PME n'étaient pas supervisés : une panne n'était connue qu'une fois signalée, et personne ne voyait charge, processeur ni température.
J'ai déployé Zabbix et Grafana sur une VM Debian : collecte SNMP toutes les 30 s, six panneaux, trois actions d'alerte par e-mail via Microsoft 365.
1 497 métriques collectées, alerte reçue en moins de 2 minutes au test de bout en bout, mené sans couper un vrai switch.
Contexte
Le réseau de l'entreprise, une PME de distribution d'une vingtaine de personnes, repose sur trois switches : un Cisco au cœur, un Cisco de distribution et un UniFi 48 ports PoE, piloté par son contrôleur. Aucun n'était supervisé.
Ce projet prolonge ma première supervision des serveurs, avec Netdata (ci-dessous), et suit la migration du cœur de réseau en 10 Gigabit, dont il surveille les liens.
Avant : Netdata, en 2024
Ma première supervision date de décembre 2024, côté serveurs. Les lenteurs se découvraient quand un utilisateur appelait : j'ai monté une VM Debian 11 avec Netdata et rattaché cinq serveurs Windows à un tableau de bord commun, avec des alertes à deux niveaux, vérifiées par une montée en charge CPU provoquée. Pour la première fois, l'état des serveurs se lisait avant qu'un utilisateur se plaigne.
Elle m'a surtout appris ce qu'il ne fallait pas refaire. Le tableau de bord local de Netdata s'ouvrait sans mot de passe, et chaque agent envoyait l'état des serveurs à Netdata Cloud, un service tiers hors de l'entreprise. Zabbix et Grafana tournent sur une VM de l'entreprise, sans confier les mesures à un service extérieur. Et les switches, eux, n'étaient toujours pas supervisés.
Ce que j'ai fait
- Installer la plateformeUne VM Debian 12 minimale sur Hyper-V porte Zabbix 7.0 LTS, avec MariaDB, et Grafana 10.4, qui lit Zabbix par un compte de service limité à la lecture.
- Préparer les CiscoInventaire des voisins par CDP depuis le switch cœur, accès SSH propre (clés RSA 2048 bits, compte local dédié), puis SNMP avec une communauté
ro: Zabbix peut interroger les switches, pas les modifier. - Tester avant d'ajouterChaque switch répond à
snmpwalkdepuis la VM avant d'entrer dans Zabbix, qui l'interroge ensuite toutes les 30 secondes. - Construire le tableau de bordSix panneaux Grafana, de la charge des interfaces à la température. Le plugin Zabbix ne se chargeait pas sous Grafana 13, la version du dépôt : j'ai installé la 10.4.
- Alerter, puis tester sans risqueUne boîte partagée Microsoft 365 envoie les alertes, pour qu'elles arrivent dans la boîte de réception principale. Pour valider la chaîne sans couper un vrai switch : un hôte fictif, sur une adresse libre.
Voir les détails techniques
Plateforme. VM sans interface graphique : 2 vCPU, 4 Go de RAM, 40 Go de disque. Zabbix depuis le dépôt officiel, base MariaDB en utf8mb4_bin, import du schéma initial, Apache pour l'interface web, fuseau Europe/Paris. Grafana avec le plugin Zabbix 4.6.1.
| Équipement | Template Zabbix | Métriques |
|---|---|---|
| Switch cœur Cisco | Cisco IOS by SNMP | 431 |
| Switch de distribution Cisco | Cisco IOS by SNMP | 577 |
| Switch UniFi 48 ports PoE | Network Generic Device by SNMP | 489 |
| Total | 1 497 |
L'écart entre les deux Cisco vient du nombre d'interfaces découvertes. Le template Cisco relève le trafic par interface (IF-MIB), le processeur (CISCO-PROCESS-MIB), la mémoire (CISCO-MEMORY-POOL-MIB) et la température (CISCO-ENVMON-MIB). Hôtes déclarés avec une interface SNMP sur le port 161 et la communauté portée par la macro {$SNMP_COMMUNITY}.
Switch UniFi. Template générique « Network Generic Device by SNMP », découverte des interfaces forcée au lieu d'attendre son cycle d'une heure : 489 métriques (48 ports cuivre, 4 ports SFP+ et les interfaces de gestion). Processeur, mémoire et température : trois OID testés, trois refus. Je l'ai documenté comme une limite de l'équipement.
Bash · tests SNMP sur le switch UniFi
# Charge CPU (UCD-SNMP)
snmpwalk <options SNMP> <ip-unifi> 1.3.6.1.4.1.2021.10.1.3
# Processeur (HOST-RESOURCES-MIB)
snmpwalk <options SNMP> <ip-unifi> 1.3.6.1.2.1.25.3.3.1.2
# MIB privée Ubiquiti
snmpwalk <options SNMP> <ip-unifi> 1.3.6.1.4.1.41112
# Même réponse pour les trois :
# No Such Object available on this agent at this OIDGrafana 13 refuse le plugin Zabbix
Le dépôt APT installait Grafana 13 ; le plugin Zabbix 4.6.1 refusait de se charger et la source de données n'était pas reconnue. C'est le plugin qui imposait la version de Grafana.
Désinstallation de la 13, installation manuelle du paquet .deb de la 10.4, avec la dépendance qui manquait sur Debian 12, puis du plugin avec grafana-cli.
Second accroc, peu documenté : pour un hôte ajouté après coup, le plugin affichait l'hôte sans ses métriques tant que son cache n'était pas vidé. Un redémarrage de grafana-server règle le problème. Chaque série est renommée (overrides) pour qu'on reconnaisse l'équipement sans lire un identifiant technique.
| Panneau | Ce qu'il montre | Valeurs observées |
|---|---|---|
| Charge des interfaces | Débit instantané de 6 ports clés, du vert au rouge | — |
| Trafic des liens 10G | Entrée et sortie des 3 switches (6 courbes) | 5 à 25 Mbit/s |
| Mémoire | Jauges des 2 Cisco | 35,7 % (cœur), 12,4 % (distribution) |
| Processeur | Courbes des 2 Cisco | Sous 45 % |
| Température | 4 capteurs (3 sur le cœur, 1 sur la distribution), alerte à 50 °C | 25 à 41 °C |
| Erreurs et pertes | Paquets rejetés et erreurs sur les liens 10G | Proches de zéro |
Alertes. Un e-mail envoyé depuis mon propre compte vers moi-même aurait été classé par Exchange hors de la boîte de réception principale ; une boîte partagée ne demande pas de licence. Le type de média Zabbix dépose les alertes directement sur la messagerie Microsoft 365 du domaine.
| Action | Condition de déclenchement |
|---|---|
| Alerte CPU élevé | Gravité ≥ Avertissement |
| Alerte Switch Down | Gravité ≥ Haute |
| Alerte Température élevée | Nom du déclencheur contenant « Temperature » |
La première action porte mal son nom : sa condition couvre tout déclencheur de gravité Avertissement ou plus, pas uniquement le processeur. L'hôte fictif « TEST-ALERTE » utilisait le template Cisco ; l'alerte a lancé l'action « Switch Down ».
L'incident
Le contrôleur UniFi refuse la configuration SNMP
L'adresse IP du switch était déjà associée à un autre client du réseau : un équipement tiers, branché sur l'un de ses ports, qui l'avait partagée par le passé.
Dans l'API du contrôleur, le réglage par équipement vérifie qu'une adresse n'appartient qu'à un client, pas le réglage au niveau du site. SNMP activé au niveau du site : switch provisionné sans erreur.
Résultats
Valeurs observées : mémoire à 35,7 % et 12,4 % sur les Cisco, processeur sous 45 %, températures de 25 à 41 °C pour un seuil d'alerte à 50 °C, erreurs proches de zéro. Le firmware UniFi n'expose que la MIB-II (interfaces, trafic, erreurs, durée de fonctionnement) : processeur, mémoire et température ne concernent que les Cisco.
Au test, le déclencheur « Cisco IOS: Unavailable by ICMP ping » s'est levé après trois cycles sans réponse, et l'e-mail est arrivé en moins de 2 minutes dans la boîte de réception principale. L'hôte fictif a été supprimé aussitôt après.
Ce que j'améliorerais
- SNMPv3 dès le départ, avec authentification et chiffrement, et une liste d'accès réservée au serveur de supervision.
- Des traps en plus de l'interrogation : la détection repose sur l'interrogation toutes les 30 secondes. J'activerais les traps utiles, comme un lien qui tombe, avec
snmp-server enable trapssur les switches et un récepteur snmptrapd côté Zabbix. - Chiffrer dès l'installation : HTTPS sur les interfaces web de supervision, envoi des alertes chiffré.