LibreNMS en 2026 : monitoring SNMP open source pour réseau et serveurs

Prometheus et Grafana ont colonisé le monitoring cloud-native. Mais quand on doit superviser des switches Cisco, des routeurs Juniper, des PDU APC, des onduleurs Eaton, des baies QNAP, des firewalls FortiGate, on revient sur SNMP. Et SNMP, c'est le terrain de LibreNMS.

LibreNMS est un fork d'Observium démarré en 2013, communautaire, sous GPLv3. Il fournit un monitoring SNMP moderne avec autodiscovery, graphing, alerting, billing, et intégration API. Pour un sysadmin qui doit donner une vue cohérente sur un parc réseau hétérogène, c'est l'outil par défaut côté open source en 2026.

Pas un concurrent de Prometheus. Un complément qui couvre le périmètre que Prometheus n'adresse pas naturellement.

• Pourquoi SNMP tient encore la route en 2026
• Architecture LibreNMS : composants et stack
• Autodiscovery et inventaire
• Graphing et capacité historique
• Alerting et intégration ticketing
• Coexistence avec Prometheus et Grafana
• Déploiement en production
• Pièges et limites

SNMP a 35 ans. Le protocole est verbeux, ses MIBs sont datées, sa sécurité (avant SNMPv3) était une plaisanterie. Mais il continue de dominer trois domaines.

Équipement réseau commercial. Cisco, Juniper, Arista, Extreme, HP, Aruba, Fortinet, MikroTik. Tous exposent leurs métriques par SNMP. La plupart n'exposent pas Prometheus natif, ou alors via un agent payant.

Hardware périphérique. PDUs, onduleurs, sondes environnementales, contrôleurs RAID, baies SAN, imprimantes pro. Tous parlent SNMP.

Conformité réseau et inventaire. Pour cartographier l'infra physique, lister les ports actifs, suivre les VLANs, le port-mapping CDP/LLDP, SNMP est la source canonique.

Ce qui ne change pas : sur ces périmètres, on n'a pas le choix. SNMP ou rien.

LibreNMS est une stack PHP / MySQL / Python avec Nginx ou Apache devant. Composants principaux :

• Frontend web PHP : UI utilisateur, tableaux de bord, configuration.
• MySQL/MariaDB : stockage des configurations, alertes, événements, inventaire.
• RRDTool ou InfluxDB : stockage des time-series. RRD par défaut, InfluxDB option moderne.
• Memcached/Redis : cache et coordination.
• Pollers : workers Python qui interrogent les équipements via SNMP. Run schedulé par cron toutes les 5 minutes.
• Discovery worker : process qui scanne pour détecter automatiquement nouveaux équipements et nouveaux capteurs.
• Alerter : moteur de règles qui évalue les conditions et envoie des notifications.

Pour les déploiements >500 devices, on scale en distribué (multi-pollers) avec partitionnement par groupes.

Côté monitoring déjà existant comme supervision-serveurs-netdata ou zabbix-monitoring-2026, LibreNMS occupe la niche "monitoring SNMP riche avec dashboards prêts à l'emploi". Zabbix peut faire le même job mais demande beaucoup plus de configuration manuelle.

C'est la valeur principale de LibreNMS comparé à un Prometheus snmp_exporter brut.

À l'ajout d'un équipement, LibreNMS interroge la sysObjectID SNMP, identifie le constructeur et le modèle via une base de OS définitions. À partir de là, il connait les MIBs spécifiques à cet équipement et peut découvrir automatiquement :

• Interfaces réseau (avec descriptions, MAC, IP)
• VLANs configurés
• Voisins CDP / LLDP (pour topologie automatique)
• Capteurs (température, ventilateurs, alimentation)
• Routes BGP, OSPF
• Sessions ARP, MAC table
• Contextes VRF
• Stockage et mémoire
• Capteurs spécifiques (PoE, optique SFP, signal-to-noise sur DSL, etc.)

L'utilisateur fait un Add Device → IP + community SNMP, et 5 minutes plus tard, le device a 200 capteurs monitorés et un dashboard auto-généré. Aucun équivalent côté Prometheus sans avoir à écrire les exporters et dashboards à la main.

Pour l'inventaire centralisé compatible IPAM, intégration avec NetBox via un plugin officiel.

RRDTool reste le défaut. C'est un format compact, rétention configurable par "RRA" (round-robin archive). Typiquement :

• Données 5 minutes pendant 48h
• Données 30 minutes pendant 1 mois
• Données 2h pendant 1 an
• Données 1 jour pendant 5 ans

Le compromis stockage / résolution est figé à la création de la RRD. Pour un parc 500 devices, prévoir 50 à 200 Go de RRD.

L'option InfluxDB stocke les time-series dans une base externe, avec rétention plus souple et requêtes plus riches. Recommandé si on veut croiser avec les données Prometheus.

Les graphes générés par LibreNMS sont éprouvés mais visuellement datés. Pour des dashboards modernes, on bascule sur Grafana qui consomme l'API LibreNMS ou directement la base InfluxDB.

LibreNMS dispose d'un moteur d'alerting riche :

• Templates personnalisables (Markdown, HTML, JSON).
• Règles déclaratives par type de capteur, par groupe, par sévérité.
• Acknowledgments avec commentaires.
• Hystérésis : seuils différents pour déclencher et résoudre.
• Maintenance windows.

Backends de notification :

• Email (SMTP)
• Slack, Teams, Discord
• PagerDuty, Opsgenie, VictorOps
• SMS via gateway (Twilio, Free Mobile, etc.)
• Webhook custom (vers des tickets, automation)
• Syslog vers SIEM (cf. rsyslog-centralisation)

Pour une équipe oncall, le combo "LibreNMS pour la détection + PagerDuty pour la rotation + Slack pour la visibilité équipe" est mature.

LibreNMS et Prometheus ne sont pas concurrents. Ils couvrent des périmètres complémentaires.

• Prometheus : applications, conteneurs, K8s, instrumentation custom. Modèle pull, exporter par sujet.
• LibreNMS : équipement réseau, hardware, capteurs SNMP. Modèle pull SNMP, autodiscovery massive.

Patterns d'intégration courants :

• Grafana central : dashboards Prometheus + InfluxDB (LibreNMS) + Loki (logs) sur la même UI.
• API LibreNMS exploitée par Grafana via le plugin LibreNMS datasource. Affichage de capteurs SNMP dans des dashboards aux côtés des métriques applicatives.
• Alertmanager unifié : LibreNMS push ses alertes vers Alertmanager via webhook. Routage et déduplication centralisés.

Pour un stack monitoring complet, voir deployer-stack-monitoring qui couvre Prometheus + Grafana + Alertmanager.

Image Docker officielle disponible. Pour un déploiement maintenable, recommandation :

version: '3.9'
services:
  librenms:
    image: librenms/librenms:latest
    depends_on:
      - db
      - redis
    environment:
      DB_HOST: db
      DB_NAME: librenms
      DB_USER: librenms
      DB_PASSWORD: <secret>
      LIBRENMS_USER: librenms
      LIBRENMS_GROUP: librenms
    volumes:
      - ./librenms:/data
    ports: ['8000:8000']
  db:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: <secret>
      MYSQL_DATABASE: librenms
      MYSQL_USER: librenms
      MYSQL_PASSWORD: <secret>
    volumes:
      - ./db:/var/lib/mysql
  redis:
    image: redis:7-alpine

Reverse proxy Nginx ou Caddy en frontal pour TLS et auth.

Sécurité SNMP : utiliser SNMPv3 partout où possible (auth+priv avec SHA-256 + AES-256). SNMPv2c reste en pratique sur les anciens équipements, segmenter le réseau de management.

Authentication LibreNMS : LDAP, SAML, OAuth (cf. keycloak-sso ou authentik-sso-moderne).

Backup MySQL nightly + dossier /data/rrd synchronisé sur S3 via Restic ou Kopia.

SNMP est lent. Polling toutes les 5 minutes par défaut. Pour de la haute résolution sur des points critiques, monter à 1 minute mais surveiller la charge poller. SNMPv3 ajoute un overhead de chiffrement.

MIBs propriétaires. Certains équipements exposent des MIBs spécifiques que LibreNMS ne reconnait pas out-of-the-box. Définition d'OS custom à écrire en YAML. Effort raisonnable mais à anticiper.

Maintenance MariaDB. La base grossit. Tables port_table_metadata, eventlog, alerts peuvent atteindre des dizaines de Go. Purge configurable mais à surveiller.

Migration RRD vers InfluxDB. Pas trivial. Si on change d'avis sur le backend, prévoir une fenêtre.

API rate limiting. L'API LibreNMS n'est pas conçue pour un usage massif (10+ req/s). Pour du polling intensif d'un Grafana, utiliser InfluxDB direct.

Communauté plus petite que Zabbix. Moins de contributeurs, moins de templates externes, mais le coeur du projet est sain et actif.

Pas de configuration as code native. La config se fait via UI ou MySQL direct. Pour un IaC complet, des wrappers Ansible / Terraform existent mais avec moins de finition que pour Prometheus.

LibreNMS convient quand le parc inclut beaucoup d'équipement réseau et hardware. Pour des stacks 100% K8s, Prometheus seul suffit. Pour des infras hybrides (DC physique + cloud + K8s), la combinaison LibreNMS + Prometheus + Grafana donne la couverture la plus large. Une supervision n'a de valeur que si quelqu'un traite les alertes la nuit ; quand cette astreinte manque en interne, la supervision se délègue.

• LibreNMS documentation officielle : install, configuration, troubleshooting.
• GitHub librenms/librenms : code, releases, communauté.
• LibreNMS supported devices : matrice OS et MIBs.
• SNMP RFC 3411 et SNMPv3 RFC 3414 : référence protocole.
• InfluxData InfluxDB documentation : backend time-series moderne.
• Net-SNMP project : référence agent SNMP côté Linux.