SNMP & télémétrie — superviser ce qu'on n'instrumente pas

Page concept

Cette page explique les grands principes de la supervision SNMP et de la télémétrie — de quoi parler avant de lancer un snmpwalk ou de configurer un Zabbix Proxy. La mise en œuvre pas à pas est dans le TP6 — Supervision SNMP avec Zabbix et les TPs associés cités plus bas. Les ressources en fin de page sont votre point de départ pour aller plus loin par vous-même.

Le concept en une phrase

Quand on ne peut pas installer d’agent (équipement réseau, onduleur, station isolée, satellite), la supervision passe par des protocoles d’interrogation (SNMP) ou des flux de télémétrie émis par l’équipement lui-même.

Un switch réseau, un onduleur industriel ou un terminal satellite ne font pas tourner de système d’exploitation où l’on peut installer node_exporter. Ils ne parlent pas Prometheus. Pourtant, ils doivent être supervisés — parfois plus que le reste, car une panne d’onduleur ou de lien satellite à Concordia ou Dumont d’Urville est autrement plus critique qu’un conteneur qui redémarre.

---

Les grands principes

1. Agent vs agentless — deux façons d’obtenir la donnée

• Avec agent — un programme installé sur la cible (un exporter Prometheus, un agent Zabbix) collecte et expose l’information localement. Riche, mais suppose qu’on puisse installer quelque chose.
• Sans agent (agentless) — on interroge la cible via un protocole qu’elle expose nativement (SNMP, une API HTTP propriétaire). Plus limité en détail, mais fonctionne sur des équipements fermés — c’est le cas de la quasi-totalité du matériel réseau et industriel.

Le choix n’est pas idéologique : il est dicté par ce que l’équipement permet.

2. SNMP — OID, MIB, polling

SNMP (Simple Network Management Protocol) est le protocole historique de supervision agentless. Son modèle mental :

• Chaque valeur exposée par l’équipement a une adresse unique, l’OID (Object Identifier) — une suite de chiffres comme 1.3.6.1.2.1.1.3.0.
• La MIB (Management Information Base) est le dictionnaire qui traduit ces OID en noms lisibles (« température du châssis », « débit de l’interface 2 »).
• Le polling consiste à interroger périodiquement ces OID — exactement le même principe de fond que le pull Prometheus, mais avec un protocole et un vocabulaire différents.

Deux limites à connaître : v2c (la version la plus répandue) transmet ses secrets d’authentification (community string) en clair, et v3 corrige ça avec chiffrement et authentification — un critère à vérifier avant de déployer sur un équipement exposé.

3. La télémétrie — le flux poussé depuis la source

À l’inverse du polling, la télémétrie est un flux que l’équipement pousse lui-même, en continu ou à intervalle très court, sans attendre d’être interrogé. C’est le modèle qu’on retrouve pour un lien satellite ou un système embarqué : le terminal émet ses propres mesures (état du modem, qualité du signal, débit) vers un collecteur, plutôt que d’attendre une requête.

Le choix entre interroger (polling) et laisser pousser (télémétrie) dépend souvent de la fréquence nécessaire et de la fiabilité du chemin retour — un point qui devient central sur un lien qui coupe.

4. Superviser sur un lien contraint — la contrainte australe

C’est le point qui distingue une supervision australe d’une supervision classique. Le lien satellite entre La Réunion, Concordia ou Dumont d’Urville impose trois contraintes qui n’existent pas sur un réseau filaire :

• Latence — plusieurs centaines de millisecondes, parfois secondes, qui rendent un polling trop fréquent coûteux et peu fiable.
• Coupures — le lien peut tomber sans prévenir ; l’absence de réponse ne veut pas dire panne de l’équipement, mais peut-être panne du lien lui-même.
• Priorisation — sur une bande passante limitée, la télémétrie de supervision doit être économe et ne pas concurrencer le trafic opérationnel.

C’est pour cette raison que l’architecture Zabbix employée dans TAAF utilise un Zabbix Proxy local à la station : le proxy collecte sur place et ne transmet vers le serveur central (à La Réunion) que des données déjà agrégées, tolérant les coupures du lien sans perdre l’historique local.

5. Zabbix vs stack Prometheus — deux philosophies

	Zabbix	Prometheus
Modèle	Polling centralisé, agents natifs + SNMP intégré	Pull, exporters dédiés par technologie
Cible type	Équipements réseau, ICS/OT, hétérogène	Services applicatifs, conteneurs
Résilience lien contraint	Zabbix Proxy natif pour sites distants	Moins conçu nativement pour ça

Les deux ne s’opposent pas dans TAAF : Prometheus/Grafana/Loki couvrent l’observabilité applicative (Acte 1 cœur), Zabbix prend le relais là où SNMP et la supervision d’équipements industriels dominent (Concordia, énergie DDU). Le SOC Grafana-natif reste le point d’affichage commun.

---

Où ça sert dans TAAF

• TP6 — Supervision SNMP avec Zabbix (Concordia + Proxy Inmarsat) — SNMP en CLI puis Zabbix distribué Server/Proxy, sur un lien Inmarsat BGAN contraint : le cœur de cette page en pratique.
• TP bonus — Supervision énergie polaire de Dumont d’Urville — extension Zabbix vers l’ICS/OT (générateur diesel, onduleur solaire, BMS, wattmètre) : l’agentless appliqué à l’énergie.
• TP5 — Télémétrie satellite (AegisSat) — le cas télémétrie poussée, avec un modèle de satellite labellisé pour détecter des attaques par sous-système.
• TP9 — Wrapper Starlink HTTP + Grafana — un équipement qui ne parle pas SNMP nativement (Starlink Dishy) : construire le pont vers Prometheus/Grafana. (TP marqué brouillon dans le dépôt à la date de rédaction.)

---

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Observabilité.

• Zabbix — documentation officielle : architecture Server/Proxy/Agent et configuration SNMP.
• RFC 3416 (SNMPv2c) : la spécification du protocole, pour qui veut la source.

À chercher par vous-même : « SNMP OID MIB polling », « SNMPv2c vs SNMPv3 », « Zabbix proxy distributed monitoring », « network telemetry vs SNMP polling ».