Superviser ses équipements réseau en SNMP avec Grafana

Une fois Grafana installé (voir le guide d'installation avec Docker Compose), la question devient : que superviser en premier ? Pour tout ce qui n'est pas un serveur Linux classique — switchs, pare-feu (dont le cluster OPNsense), onduleurs, imprimantes réseau, NAS — le protocole universel reste SNMP. Quasiment tous les équipements réseau l'exposent nativement, sans agent à installer. Voici comment le brancher proprement sur une stack Prometheus + Grafana.

1. Activer SNMP sur l'équipement à superviser

Avant toute config côté supervision, il faut activer SNMP côté équipement. Sur un pare-feu OPNsense par exemple : Services → SNMP, puis :

• Choisir une communauté en lecture seule (jamais la valeur par défaut public), ou mieux, activer SNMPv3 avec authentification et chiffrement si l'équipement le supporte.
• Restreindre la source autorisée à interroger l'agent SNMP à la seule IP du serveur de supervision (règle de pare-feu dédiée), jamais ouvert à tout le LAN et encore moins au WAN.
• Activer uniquement les MIB dont vous avez besoin (interfaces, état matériel...) plutôt que tout exposer par défaut.

2. Générer le fichier snmp.yml avec le générateur officiel

snmp_exporter ne devine pas tout seul quelles métriques extraire d'un équipement : il a besoin d'un fichier snmp.yml généré à partir des MIB du constructeur. Le générateur officiel s'utilise via Docker, sans rien installer sur la machine hôte :

# Fichier de config minimal pour le générateur (generator.yml)
$ cat > generator.yml <<'EOF'
modules:
  if_mib:
    walk:
      - 1.3.6.1.2.1.2        # IF-MIB (interfaces, trafic, erreurs)
      - 1.3.6.1.2.1.31.1.1   # IF-MIB étendu (compteurs 64 bits)
EOF

# Génération du snmp.yml à partir des MIB standards embarquées
$ docker run --rm -v "$(pwd):/opt/snmp_exporter" \
    prom/snmp-generator generate

Pour un équipement avec des compteurs propriétaires (température, état d'alimentation redondante, capacité de batterie d'un onduleur...), on ajoute simplement les OID ou MIB constructeur correspondants dans generator.yml avant de relancer la génération.

3. Ajouter snmp_exporter et Prometheus au docker-compose.yml

En reprenant le fichier du guide d'installation de Grafana, on ajoute deux services :

services:
  snmp_exporter:
    image: prom/snmp-exporter:latest
    container_name: snmp_exporter
    restart: unless-stopped
    volumes:
      - ./snmp.yml:/etc/snmp_exporter/snmp.yml
    ports:
      - "19116:9116"    # port hôte à adapter selon ce qui est déjà utilisé chez vous

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "19090:9090"   # idem, port hôte à adapter

volumes:
  prometheus-data:

Et le fichier prometheus.yml qui définit la cible SNMP à interroger — le principe clé est que Prometheus n'interroge pas directement l'équipement, mais passe par snmp_exporter en lui donnant l'IP cible en paramètre :

scrape_configs:
  - job_name: snmp
    static_configs:
      - targets:
          - 192.0.2.10    # IP de l'équipement à interroger (ex. pare-feu, switch) — adaptez à votre réseau
    metrics_path: /snmp
    params:
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp_exporter:9116

Ce bloc de relabel_configs est le cœur du fonctionnement : il redirige la requête vers snmp_exporter tout en conservant l'IP réelle de l'équipement comme label instance, pour que les métriques restent identifiables une fois dans Grafana.

4. Connecter Grafana et importer un dashboard

Dans Grafana, ajoutez Prometheus comme source de données (Connections → Data sources, URL http://prometheus:9090), puis importez un dashboard communautaire dédié au SNMP/IF-MIB (plusieurs sont disponibles sur grafana.com/dashboards, recherche "SNMP" ou "Interface traffic") pour obtenir immédiatement des graphiques de bande passante par interface, de taux d'erreurs et de paquets rejetés.

Sur un pare-feu ou un switch de cœur de réseau, le trafic par interface et le taux d'erreurs sont les deux métriques qui préviennent le plus tôt d'un problème — un câble qui se dégrade ou un lien qui sature se voient sur ces courbes bien avant qu'un utilisateur ne s'en plaigne.

5. Alerter sur les métriques importantes

Une fois les données présentes, quelques règles d'alerte simples dans Grafana couvrent l'essentiel :

• Interface down : valeur ifOperStatus différente de "up" sur une interface qui devrait toujours l'être.
• Perte de polling : absence de nouvelle métrique depuis un équipement pendant plus de quelques minutes (l'agent SNMP ou l'équipement lui-même ne répond plus).
• Saturation de lien : trafic proche de la capacité nominale de l'interface sur une durée soutenue, plutôt qu'un pic ponctuel normal.

Conclusion

SNMP reste, malgré son âge, le dénominateur commun de la quasi-totalité du matériel réseau — c'est justement ce qui en fait un excellent point de départ pour une supervision qui couvre large sans agent à déployer partout. Avec snmp_exporter, Prometheus et Grafana, la même stack qui sert déjà à superviser vos serveurs peut englober switchs, pare-feu et onduleurs en quelques fichiers de configuration. Si vous voulez être accompagné sur la mise en place de votre supervision réseau, n'hésitez pas à me contacter.