⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Introduction : La Tentation de l’Uniformité

Lors de la conception d’une architecture de monitoring pour une infrastructure réseau, l’approche “tout SNMP” semble initialement séduisante. Ce protocole standardisé depuis plus de 30 ans promet une collecte de métriques unifiée et agentless (sans installation d’agent sur les équipements cibles).

Dans le cadre de mon projet de monitoring d’infrastructure, j’ai initialement opté pour cette stratégie. La réalité du terrain m’a rapidement confronté aux limites de cette approche, me conduisant à pivoter vers une architecture hybride combinant SNMP et Node Exporter.

Cet article documente ce cheminement technique et les enseignements tirés de cette expérience.

Les limites constatées du SNMP : l’exemple du pfSense

Contexte technique

Mon objectif initial était d’interroger mon routeur pfSense exclusivement via SNMP, en activant simplement le service dans l’interface web et en configurant Prometheus pour la collecte des métriques.

Problématique rencontrée

L’implémentation s’est heurtée à des erreurs HTTP 400 (Bad Request) récurrentes. L’analyse a révélé que le module host_resources_mib, censé exposer les métriques CPU et RAM, n’était pas correctement implémenté ou présentait des incompatibilités avec la version de SNMP Exporter utilisée (v0.29.0).

Analyse des limitations

Le protocole SNMP fonctionne selon un modèle d’interrogation distante : le collecteur interroge des OID (Object Identifiers) définis dans une MIB (Management Information Base). Cette approche présente plusieurs contraintes :

Le protocole présente plusieurs limitations notables :

La visibilité système est limitée : impossibilité d’obtenir des métriques avancées (température SMART des disques) sans scripts additionnels complexes, avec une granularité insuffisante sur certaines ressources (moyenne CPU globale plutôt que charge par cœur).

L’impact sur les ressources peut être significatif : le démon snmpd peut consommer des ressources appréciables sur des équipements de capacité modeste lors de collectes volumineuses.

Il existe une dépendance critique aux implémentations constructeur, car la qualité et l’exhaustivité des MIB varient selon les équipements et leurs fabricants.

L’adoption de Node Exporter : une approche complémentaire

Principe de fonctionnement

Node Exporter se distingue fondamentalement du SNMP par son positionnement : il s’agit d’un agent qui s’exécute directement au sein du système d’exploitation cible. Cette position lui confère un accès privilégié aux interfaces kernel (Linux/FreeBSD), permettant une collecte de métriques exhaustive et précise.

Déploiement sur Proxmox (Debian-based)

L’installation sur l’hyperviseur Proxmox s’effectue via le gestionnaire de paquets système :

1

sudo apt update && sudo apt install prometheus-node-exporter -y

Le paquet officiel de la distribution offre plusieurs avantages : intégration automatique dans le système de mises à jour de sécurité, signatures cryptographiques vérifiées, et configuration par défaut validée par les mainteneurs Debian.

Configuration Prometheus : architecture hybride

La configuration finale intègre deux types de collecteurs distincts dans le fichier prometheus.yml :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

scrape_configs:
  # --- Collecte système (Node Exporter) ---
  - job_name: 'serveur-coeur-system'
    scrape_interval: 15s
    static_configs:
      - targets: 
          - '10.0.0.10:9100'  # Proxmox
          - '10.0.0.1:9100'   # pfSense
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'node_.*'
        action: keep
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
      - target_label: security_level
        replacement: 'critical'

  # --- Collecte réseau (SNMP) ---
  - job_name: 'switch-mikrotik'
    static_configs:
      - targets: ['10.0.0.254']
    metrics_path: /snmp
    params:
      auth: [public_v2]
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: 10.0.0.5:9116  # Conteneur snmp-exporter

Analyse de la configuration

Pour Node Exporter, l’intervalle de collecte est réduit à 15 secondes pour les serveurs critiques, permettant une détection rapide d’anomalies. Le filtrage des métriques conserve uniquement celles préfixées node_, réduisant le volume de données stockées.

Pour SNMP, Prometheus utilise un mécanisme de proxy : il envoie une requête HTTP au conteneur snmp-exporter (port 9116), qui traduit cette requête en paquets UDP SNMP vers l’équipement cible.

Perspective sécurité : défense en profondeur

Analyse comparative des surfaces d’attaque

Node Exporter offre une exposition HTTP sur port unique (9100), facilitant la mise en place de règles de filtrage précises et la restriction d’accès par ACL firewall à l’IP source du serveur Prometheus uniquement. Le trafic est compacté en une seule transmission HTTP, réduisant la surface d’écoute réseau. Il nécessite cependant l’installation d’un agent sur le système cible.

SNMP (version 2c) présente des limitations sécurité : la “communauté” (équivalent mot de passe) est transmise en clair sur le réseau, ce qui crée une vulnérabilité à l’interception par analyse de trafic. Les multiples allers-retours réseau (GetNextRequest) facilitent en outre la détection et les tentatives de perturbation.

Test de validation de la segmentation réseau

Pour vérifier l’efficacité du cloisonnement réseau, j’ai effectué un test d’accès depuis un VLAN distinct (réseau invité) :

1

curl --connect-timeout 5 http://10.0.0.10:9100/metrics

Résultat attendu : Timeout de connexion, confirmant que les règles de pare-feu interdisent l’accès inter-VLAN non autorisé.

Résultat préoccupant : Réponse HTTP 200, indiquant une configuration de segmentation à revoir.

Résultats opérationnels

L’architecture hybride a significativement amélioré la visibilité sur l’infrastructure. Avant, avec SNMP exclusif, la collecte était incomplète avec discontinuités dans les séries temporelles, et la visibilité était limitée sur l’activité disque et la charge détaillée des processeurs. Après intégration de l’approche hybride, nous avons obtenu une granularité fine sur l’ensemble des ressources système et la possibilité de créer des alertes avancées basées sur des corrélations de métriques.

Exemple : Détection d’activité suspecte

L’accès aux métriques détaillées a permis la mise en place d’une alerte de détection d’activité anormale sur le NAS :

1
2
3
4
5
6

- alert: SuspiciousWriteActivity
  expr: rate(node_disk_written_bytes_total[5m]) > 100000000  # >100 MB/s
  for: 10m
  annotations:
    summary: "Écriture disque massive détectée sur {{ $labels.instance }}"
    description: "Activité d'écriture inhabituelle : {{ $value | humanize }}B/s"

Cette alerte surveille le débit d’écriture sur les disques. Une écriture massive et soutenue en dehors des fenêtres de backup planifiées peut indiquer une compromission (chiffrement ransomware, exfiltration de données).

Conclusion

L’architecture de monitoring efficace repose sur le choix de l’outil adapté à chaque cas d’usage plutôt que sur la recherche d’une uniformité technique absolue.

La répartition retenue distingue SNMP pour les équipements réseau purs (switches, routeurs) où il conserve sa pertinence, et Node Exporter pour les serveurs et systèmes critiques nécessitant une visibilité système exhaustive.

Cette architecture constitue désormais le socle de ma plateforme de supervision. Le prochain article abordera la sécurisation des accès à ces données via l’utilisation de Docker Secrets et de fichiers d’environnement pour une gestion sécurisée des identifiants.