Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026

📡 Supervision (Monitoring) – SNMP, NetFlow, Logs & Outils

Guide complet IDEO-Lab sur la collecte, l'analyse et l'alerte des métriques réseau.

1.1

Concept & Piliers

Proactif vs Réactif. Les 3 piliers (Dispo, Perf, Logs).

Supervision Proactif
1.2

Métriques & Concepts

Baseline, Alerting, Métriques (Latence, CPU...).

Baseline Alerting
1.3

NMT (Network Management)

Systèmes NMS, OOB Management.

NMS Out-of-Band
2.1

Disponibilité : ICMP

Protocole ICMP (Ping, Echo Request/Reply).

ICMP Ping Disponibilité
2.2

Disponibilité : fping

Outil de ping en parallèle (multi-cibles).

fping Scan
2.3

Performance : Smokeping

Outil de graphing (Latence, Gigue, Perte) via RRDtool.

Smokeping Latence RRDtool
3.1

Protocole : SNMP

Simple Network Management Protocol (Agent, Manager).

SNMP Performance
3.2

SNMP : GET vs TRAP

Polling (Pull) vs. Alertes (Push).

SNMP GET SNMP TRAP
3.3

SNMP : MIB & OID

MIB (Dictionnaire) & OID (Adresse de la métrique).

MIB OID
4.1

Protocole : NetFlow

Analyse de flux (Qui parle à qui ?). 7-Tuple.

NetFlow Cisco Visibilité
4.2

Variantes : sFlow, J-Flow

sFlow (Sampling) vs NetFlow v9 (Template).

sFlow J-Flow
4.3

Outils Flux (Collector)

nfdump, nfsen, PRTG, SolarWinds NTA.

nfdump Collector
5.1

Protocole : Syslog

Standard de logging (PUSH, UDP 514), Niveaux (0-7).

Syslog Logs UDP 514
5.2

Outil : ELK Stack

Elasticsearch, Logstash, Kibana, Beats. Analyse L7.

ELK Elasticsearch
5.3

Outils : Splunk & Graylog

Alternatives à ELK (Commercial vs Open Source).

Splunk Graylog
6.1

NMS : Nagios / Icinga 2

Classique, Check-based (Scripts), Alerte (0-3).

Nagios Icinga 2
6.2

NMS : Zabbix

All-in-one, Agent/Agentless, Auto-discovery.

Zabbix Agent
6.3

NMS : Prometheus & Grafana

Moderne, Pull (Scrape), Time-Series DB, Dashboards.

Prometheus Grafana
7.1

Cheat-sheet : Protocoles

SNMP vs NetFlow vs Syslog.

Comparatif Protocoles
7.2

Cheat-sheet : Outils NMS

Nagios vs Zabbix vs Prometheus.

Comparatif Outils
7.3

Cheat-sheet : Outils SNMP

snmpwalk, snmpget. (Linux).

snmpwalk snmpget
1.1 Concept & Piliers de la Supervision
Qu'est-ce que la Supervision (Monitoring) ?

La supervision réseau (Network Monitoring) est le processus continu de collecte et d'analyse de données sur l'état et la performance d'un réseau informatique et de ses composants (routeurs, switchs, serveurs, applications).

L'objectif est de passer d'une gestion réactive à une gestion proactive :

  • Réactif : "Le téléphone sonne. Le PDG dit que le site est lent." (Échec).
  • Proactif : "Je reçois une alerte. L'usage CPU du serveur web est à 90% depuis 5 minutes. Je vais investiguer *avant* que le PDG ne s'en rende compte." (Succès).
Les 3 Piliers de la Visibilité (M.E.L.T)

Une supervision complète repose sur trois types de données (parfois appelés les 3 piliers, ou "Metrics, Events, Logs, Traces") :

PilierQuestionExemples de Métriques/DonnéesProtocole Clé
Disponibilité (Fault)Est-ce UP ou DOWN ?Statut (Up/Down), Perte de paquets (Loss).ICMP (Ping)
Performance (Metrics)Est-ce LENT ou PLEIN ?CPU (%), RAM (%), Bande Passante (bps), Latence (ms).SNMP, WMI
Logs (Events)Que s'est-il PASSÉ ?"Login Échoué", "Port Fa0/1 Down", "Config Modifiée".Syslog, SNMP Traps
Flux (Flows/Traces)QUI parle à QUI ?"IP A a envoyé 500MB à IP B sur le port 443".NetFlow, sFlow
1.2 Métriques & Concepts (Baseline, Alerting)
Métriques (Ce qu'on mesure)
  • Disponibilité (Fault) :
    • Ping (ICMP) : L'hôte répond-il ?
    • Port Check (TCP) : Le service (ex: Port 80) répond-il ?
    • Perte de Paquets (Loss) : (ex: 5% de perte).
  • Performance (Ressources) :
    • Bande Passante (Bandwidth) : (bits/sec) Utilisation du lien WAN.
    • Latence (Latency) : (ms) Temps de réponse.
    • Gigue (Jitter) : (ms) Variation de la latence (critique pour la VoIP).
    • CPU Load : (%) Charge du processeur (du routeur ou serveur).
    • Memory Usage : (%) Utilisation de la RAM.
    • Disk Usage : (%) Espace disque (critique pour les serveurs de logs).
Baseline (Ligne de Base)

C'est la "norme" de votre réseau. La supervision collecte des données sur une longue période (ex: 1 mois) pour établir ce qui est normal.

Exemple de Baseline : "L'usage CPU de ce serveur est de 20% en journée, 70% pendant la sauvegarde de 2h du matin, et le reste du temps à 5%."

Alerting (Alertes)

L'alerte est déclenchée quand une métrique dévie de la baseline. C'est le passage au "proactif".

  • Seuil Statique : (Simple) ALERTE si CPU > 90% pendant 5 min.
  • Seuil Dynamique : (Intelligent) ALERTE si CPU > 30% à 4h du matin (anormal selon la baseline).
1.3 Network Management (NMS)
NMS (Network Management System)

Le NMS est le serveur central qui exécute le logiciel de supervision (ex: Nagios, Zabbix, SolarWinds).

C'est le "Manager" qui effectue le "Polling" (interrogation) de tous les "Agents" (switchs, routeurs, serveurs) du réseau.

In-Band vs. Out-of-Band (OOB) Management

Comment l'admin accède-t-il au NMS et aux appareils ?

In-Band (Dans la bande)

(Défaut) On utilise le réseau de production (le même que les utilisateurs) pour superviser et administrer (ex: SSH, SNMP).

Risque : Si le réseau de production tombe (ex: boucle STP, panne de routage), vous perdez aussi l'accès à vos switchs/routeurs pour le dépanner.

Out-of-Band (OOB) (Hors bande)

(Bonne pratique) On construit un deuxième réseau physique, totalement séparé (switchs dédiés, 4G/LTE), utilisé uniquement pour l'administration (Ports "Mgmt", "Console").

Avantage : Si le réseau de production tombe, le réseau OOB est toujours UP, permettant à l'admin de se connecter pour diagnostiquer.

2.1 Disponibilité : ICMP (Ping)

ICMP (Internet Control Message Protocol) est un protocole de Couche 3 (Réseau) utilisé pour le diagnostic et les messages d'erreur (il n'transporte pas de données utilisateur).

Ping (Echo Request / Echo Reply)

C'est l'outil de base de la supervision de disponibilité.

La commande ping envoie un paquet ICMP Type 8 (Echo Request) à une destination.

Si la destination est joignable, elle répond avec un paquet ICMP Type 0 (Echo Reply).

Usage en Supervision (Nagios, Zabbix...)

Le NMS "ping" toutes les 1 ou 5 minutes chaque appareil critique (serveur, routeur) :

  • Réponse reçue (temps=10ms) : Hôte = UP.
  • "Request Timed Out" (Perte) : Hôte = DOWN (-> Alerte !).
2.2 Disponibilité : fping

fping (Fast Ping) est un outil (Linux) similaire à ping, mais optimisé pour la supervision de multiples cibles (scanning).

ping vs fping
  • ping (séquentiel) : Envoie paquet 1, attend réponse 1. Envoie paquet 2, attend réponse 2. (Lent pour 1000 hôtes).
  • fping (parallèle) : Envoie 1000 paquets (mode round-robin) puis écoute les réponses. (Très rapide).
Exemple d'usage

Scanner tout un sous-réseau (-g) et n'afficher que les hôtes "Alive" (-a) :

$ fping -a -g 192.168.1.0/24

192.168.1.1 is alive
192.168.1.10 is alive
192.168.1.50 is alive

C'est souvent le moteur utilisé par les NMS (Nagios, Zabbix) pour le "Network Discovery".

2.3 Performance : Smokeping (Latence/Gigue)

Smokeping est un outil de supervision (open-source) spécialisé dans la visualisation de la qualité de la connexion (Latence, Gigue, Perte).

Fonctionnement (RRDtool)

Il "ping" (ou utilise d'autres sondes) en continu (ex: 20 pings toutes les 5 minutes) des cibles (ex: 8.8.8.8, votre passerelle FAI, votre serveur web).

Il stocke les résultats (Latence min/max/moyenne, Perte) dans une base de données RRDtool (Round Robin Database), qui est optimisée pour les données "Time-Series" (horodatées).

Résultat (Le "Smokegraph")

Il génère des graphiques "Smokegraphs" :

  • L'axe X est le temps (ex: 24h).
  • L'axe Y est la latence (ex: 0-100ms).
  • La zone "pleine" (Médiane) est en vert.
  • La "fumée" (en gris) représente la Gigue (Jitter) (la variation entre min/max).
  • Les barres rouges représentent la Perte (Loss).

Permet de voir en un coup d'œil si un lien WAN est stable ou non.

3.1 Protocole : SNMP (Simple Network Management Protocol)
L'Outil de Supervision "Performance"

SNMP est le protocole standard (Couche 7, UDP 161/162) utilisé pour superviser (monitorer) et gérer des équipements réseau (switchs, routeurs, serveurs, imprimantes...).

C'est le protocole n°1 pour la supervision de performance (CPU, RAM, Bande Passante).

Composants
  • Manager (NMS) : Le serveur de supervision (ex: Nagios, Zabbix) qui pose les questions.
  • Agent : Le logiciel qui tourne sur l'appareil (ex: le switch Cisco) et qui possède les réponses.
  • MIB (Management Information Base) : Le "dictionnaire" (voir 3.3) que le Manager utilise pour savoir quelles questions poser.
Versions & Sécurité
VersionSécurité (Authentification)Statut
SNMPv1"Community String" (Texte clair, ex: "public").Obsolète (Non sécurisé).
SNMPv2c"Community String" (Texte clair).Courant (Non sécurisé). (Utilisé en interne, bloqué par les firewalls). Ajoute le GetBulk.
SNMPv3Utilisateur + Mdp (MD5/SHA) + Chiffrement (DES/AES).Moderne (Sécurisé). Recommandé, mais plus complexe à configurer.
3.2 SNMP : GET (Pull) vs TRAP (Push)

SNMP utilise deux modes de communication (sur des ports UDP différents).

Polling (Pull) - Port UDP 161

C'est le mode le plus courant, utilisé pour la performance.

Le Manager (NMS) initie la requête (ex: toutes les 5 minutes).

  • GET Request : "Donne-moi la valeur de l'OID X (ex: CPU)."
  • GETNEXT Request : "Donne-moi la valeur de l'OID suivant X."
  • GETBULK Request : (v2c+) "Donne-moi les 10 prochains OIDs." (Efficace).
  • SET Request : (Rare, dangereux) "Change la valeur de l'OID Y." (Gestion).
Traps (Push) - Port UDP 162

C'est le mode d'alerte, utilisé pour les pannes (faults).

L'Agent (Switch) initie la requête (non sollicitée).

Exemple :
1. Le Port Fa0/1 tombe (DOWN).
2. L'Agent (Switch) envoie immédiatement
   un "SNMP TRAP" au Manager (NMS).
3. Message : "Port Fa0/1 est DOWN !"

(Le NMS n'a pas eu à attendre le
 prochain cycle de polling de 5 min
 pour le découvrir).
3.3 SNMP : MIB & OID
Le "Dictionnaire" des Métriques

MIB (Management Information Base) : Un "dictionnaire" (un fichier texte structuré) qui décrit toutes les variables (métriques) qu'un appareil peut superviser. (ex: IF-MIB pour les interfaces, HOST-RESOURCES-MIB pour CPU/RAM).

OID (Object Identifier) : L'"adresse" unique, numérique et hiérarchique (arborescente) d'une métrique spécifique.

Structure de l'arbre OID :
1 (iso)
 └ 3 (org)
   └ 6 (dod)
     └ 1 (internet)
       └ 2 (mgmt)
         └ 1 (mib-2)
           └ 1 (system)
             └ 1 (sysDescr) -> .1.3.6.1.2.1.1.1.0
             └ 3 (sysUpTime) -> .1.3.6.1.2.1.1.3.0
           └ 2 (interfaces)
             └ 2 (ifTable)
               └ 1 (ifEntry)
                 └ 10 (ifInOctets - Octets entrants)
                    └ .1 (Interface 1) -> .1.3.6.1.2.1.2.2.1.10.1
                    └ .2 (Interface 2) -> .1.3.6.1.2.1.2.2.1.10.2
Outil : snmpwalk (Linux)

L'outil de diagnostic de base. Il utilise GETNEXT en boucle pour "marcher" (walk) dans l'arbre OID d'un agent et afficher toutes les valeurs.

# Commande pour "walker" toute la branche 'system'
# -v2c : Utilise la version 2c
# -c public : Utilise la community "public"
# 192.168.1.1 : Cible (Agent)
# .1.3.6.1.2.1.1 : OID de départ (system)

$ snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1

iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software..." (sysDescr)
iso.3.6.1.2.1.1.2.0 = OID: ... (sysObjectID)
iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day... (sysUpTime)
...
Outil : snmpget

Demande un seul OID.

$ snmpget -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day...
4.1 Protocole : NetFlow (Analyse de Flux)
Le "Qui-Quoi-Où" du Trafic

Problème : SNMP vous dit : "Votre lien WAN est saturé (90% d'utilisation)". Mais il ne vous dit pas POURQUOI (Qui ? Quel service ?).

NetFlow (protocole inventé par Cisco) est la solution. Il analyse le trafic et génère des "méta-données" sur les flux (flows).

Qu'est-ce qu'un "Flow" (Flux) ?

C'est une "conversation" unidirectionnelle, identifiée par le 7-Tuple :

  1. IP Source
  2. IP Destination
  3. Port Source
  4. Port Destination
  5. Protocole (TCP/UDP)
  6. Interface d'entrée
  7. Type of Service (ToS / DSCP)
Architecture

NetFlow (Push) est composé de 3 éléments :

  • Exporter : Le routeur/switch qui voit le trafic. Il analyse les paquets, agrège les statistiques (ex: "Flow A = 500 paquets, 50MB") et exporte (PUSH) ces métadonnées.
  • Collector : Un serveur (dédié) qui "écoute" (UDP 2055, 9996...) et collecte/stocke ces rapports de flux.
  • Analyzer : Une interface graphique (NMS) qui lit les données du Collector pour générer des graphiques (ex: "Top Talkers", "Top Applications").
4.2 Variantes : NetFlow, sFlow, J-Flow
ProtocolePropriétaireMéthodeDescription
NetFlow v5CiscoStateful (Cache)Version "fixe" (legacy). Capture 100% du trafic, l'agrège dans le cache du routeur, puis l'exporte. (Lourd pour le routeur).
NetFlow v9CiscoStateful (Template)Moderne. Le routeur envoie d'abord un "template" (structure) au Collector, puis envoie les flux. (Standard *de facto*).
IPFIXIETFStateful (Template)Le standard "officiel" (IETF) basé sur NetFlow v9.
J-FlowJuniperStateful (Template)L'implémentation de Juniper (similaire à NetFlow v9).
sFlowInMon (HP...)Stateless (Sampling)(Concurrent). Ne suit pas les flux. Il échantillonne (samples) 1 paquet sur N (ex: 1/1000). Très léger pour le routeur, mais moins précis.
4.3 Outils d'Analyse de Flux

L'écosystème NetFlow nécessite un "Collector" et un "Analyzer".

Outils Open Source
  • nfdump / nfsen : (CLI / Web) Outils (Linux) de base. nfdump capture et filtre les flux. nfsen est une ancienne interface web pour nfdump.
  • Elastiflow : Un pipeline moderne basé sur ELK Stack. Utilise Logstash pour recevoir les flux et Kibana pour les visualiser (très puissant).
Outils Commerciaux (NMS)
  • PRTG Network Monitor : Intègre un collecteur de flux (NetFlow, sFlow).
  • SolarWinds NTA (NetFlow Traffic Analyzer) : Module spécialisé pour SolarWinds Orion.
5.1 Pilier 3 : Logs (Syslog)
Le "Journal de Bord" du Réseau

Syslog est un protocole de logging (journalisation) standard (Couche 7). C'est un protocole "PUSH" (non-fiable).

Les appareils (routeurs, switchs, firewalls, serveurs Linux) envoient (poussent) leurs messages d'événements (logs) à un Serveur Syslog central (le "Collector").

Transport : Utilise UDP 514 (Défaut, non fiable) ou TCP 514 / TCP 6514 (Syslog-NG/RELP, fiable).

Format (Exemple)
<34> Oct 11 22:14:15 [Switch-A] %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
Niveaux de Sévérité (Severity)

Les logs sont classés par niveau de criticité (de 0 à 7).

NiveauMot-cléDescription
0EmergencySystème inutilisable (Panic).
1AlertAction immédiate requise (ex: Corruption).
2CriticalErreur critique (ex: Panne matérielle).
3ErrorErreur (ex: %LINK-3-UPDOWN).
4WarningAvertissement (ex: Config modifiée).
5NoticeÉvénement normal mais significatif.
6InformationalInformation (ex: Login réussi).
7DebugVerbeux (pour débogage uniquement).
5.2 Outil : ELK Stack (Elastic)

Le Stack ELK (Elastic) est la solution open-source leader pour l'agrégation et l'analyse de logs (Log Management).

C'est le moteur de nombreux SIEM (Security Information and Event Management).

Composants (ELKB)
[Serveurs/Routeurs] ──(Logs)──► [ BEATS ]
                                   │
                                   ▼
                             [ LOGSTASH ]
 (Collecte, Parse (Grok), Enrichit)
                                   │
                                   ▼
                       [ ELASTICSEARCH ]
 (Base de données NoSQL. Indexe, Stocke)
                                   │
                                   ▼
                               [ KIBANA ]
 (Interface Web, Visualisation, Dashboards)
  • Beats : Agents légers (ex: Filebeat lit /var/log, Packetbeat analyse le réseau).
  • Logstash : Le pipeline "ETL". Reçoit de Beats, parse les logs (via filtres Grok) pour les structurer (de "Login failed for user bob" à {user: "bob", status: "failed"}).
  • Elasticsearch : La base de données NoSQL qui stocke et indexe ces logs structurés (JSON).
  • Kibana : L'interface web (UI) pour rechercher, visualiser et créer des dashboards.
5.3 Outils : Splunk & Graylog

Alternatives populaires à ELK pour la gestion de logs (SIEM).

Splunk

Modèle : Commercial (Très cher).

Le leader "historique" du marché SIEM. Extrêmement puissant, rapide, et "facile" (comparé à ELK).

  • Avantage : Tout-en-un (Collector, Indexer, GUI). Langage de requête (SPL).
  • Inconvénient : Coût (licence basée sur le volume de logs/jour).
Graylog

Modèle : Open Source (avec version Enterprise).

Un concurrent direct d'ELK, souvent considéré comme plus simple à mettre en place pour la gestion de logs pure.

  • Avantage : Plus "intégré" qu'ELK (Logstash+Elastic+Kibana).
  • Technologie : Utilise Elasticsearch (ou OpenSearch) en backend, mais remplace Logstash/Kibana par sa propre stack (Java/MongoDB).
6.1 NMS : Nagios / Icinga 2

Nagios est le NMS "classique" (open-source), très robuste. Icinga 2 est un fork moderne de Nagios.

Modèle "Check-Based" (Basé sur les Vérifications)

Nagios est un ordonnanceur (scheduler). Il n'effectue aucune supervision lui-même. Il se contente d'exécuter des scripts (Plugins) à intervalle régulier.

Plugin : Un script (Bash, Perl, Python) qui vérifie UNE chose et retourne un code de sortie.

(Exemple : check_ping)
$ /usr/lib/nagios/plugins/check_ping -H 8.8.8.8 -w 100,5% -c 200,10%
OK - 8.8.8.8: rta 10.5ms, lost 0% | ...
$ echo $?
0
Codes de Sortie (États)
CodeÉtatDescription
0OKLe service fonctionne.
1WARNINGAvertissement (ex: Disque > 80%).
2CRITICALPanne (ex: Hôte DOWN, Disque > 95%). -> Alerte !
3UNKNOWNErreur de plugin (ex: SNMP timeout).
6.2 NMS : Zabbix

Zabbix est une solution de supervision "tout-en-un" (open-source) qui concurrence Nagios, mais avec une approche plus intégrée.

Agent vs. Agentless

Zabbix supporte plusieurs méthodes de collecte :

  • Agent (Zabbix Agent) : (Recommandé) Un petit binaire (zabbix_agentd) tourne sur le serveur/client. Le NMS (Serveur Zabbix) l'interroge. (Permet des checks L7 complexes, ex: "check_mysql_query").
  • Agentless (Sans Agent) : (Pour les équipements réseau) Le NMS utilise des protocoles standards :
    • ICMP : (Ping) pour la disponibilité.
    • SNMP : (Polling) pour les métriques (CPU, Trafic...).
Fonctionnalités (All-in-One)

Contrairement à Nagios (qui a besoin de RRDtool/PNP4Nagios pour les graphs), Zabbix inclut tout :

  • Collecte : (Agent, SNMP, ICMP).
  • Stockage : (Base de données SQL - MySQL/Postgres).
  • Graphing : (Génération de graphiques).
  • Alerting : (Gestion des alertes).
  • Web UI : (Interface de configuration et de dashboards).
  • Auto-Discovery : Peut scanner un réseau et ajouter automatiquement les hôtes trouvés.
6.3 NMS : Prometheus & Grafana (Moderne)

Prometheus est la solution open-source (CNCF) de monitoring de référence pour les environnements Cloud Native (Conteneurs, Kubernetes, Microservices). Il est souvent couplé à Grafana pour la visualisation.

Prometheus (Modèle PULL)

Contrairement à Zabbix (Agent) ou Syslog (Push), Prometheus utilise un modèle PULL (Scrape).

Fonctionnement :

  1. Les cibles (serveurs, applications) exposent leurs métriques sur un endpoint HTTP (ex: http://serveur:9100/metrics). C'est un Exporter (ex: node_exporter).
  2. Le serveur Prometheus "scrape" (interroge) ce endpoint toutes les 15 ou 30 secondes (Pull).
  3. Il stocke les données dans sa propre TSDB (Time-Series Database).
  4. Il gère les alertes (via Alertmanager).
Grafana (Visualisation)

Grafana est un outil de visualisation (Dashboarding) open-source (concurrent de Kibana).

Il ne collecte et ne stocke rien. C'est une interface "lecture seule".

Fonctionnement :

  1. Vous ajoutez une "Data Source" (ex: Prometheus, Elasticsearch, Zabbix, MySQL...).
  2. Vous créez un Dashboard.
  3. Vous ajoutez un Panel (graphique).
  4. Vous écrivez une requête (ex: PromQL) pour récupérer les données de Prometheus.
  5. Grafana affiche le graphique.
7.1 Cheat-sheet : Protocoles de Supervision
ProtocoleTypeUsage PrincipalQuestion Répondue
ICMP (Ping)Polling (Pull)Disponibilité (Fault)"Est-il UP ou DOWN ?"
SNMP (GET)Polling (Pull)Performance (Metrics)"Quel est son CPU ? Sa Bande Passante ?"
SNMP (TRAP)Événement (Push)Disponibilité (Fault)"Un port vient de TOMBER !"
SyslogÉvénement (Push)Logs (Events)"QUE s'est-il passé ? (ex: Login échoué)"
NetFlow / sFlowFlux (Push)Visibilité (Traces)"QUI (IP) a saturé la bande passante et avec QUOI (Port) ?"
7.2 Cheat-sheet : Outils NMS (Comparatif)
OutilModèleUsage PrincipalGraphing
Nagios / Icinga 2Check-based (Scripts)Alerting (Up/Down). (Check OK/Warn/Crit).Séparé (RRDtool, PNP4Nagios).
ZabbixAgent / Agentless (Pull)Monitoring All-in-One (Serveurs, Réseau).Intégré (simple).
PrometheusPull (Scrape Exporters)Monitoring Cloud/Conteneurs (Time-Series).Séparé (Grafana).
ELK StackPush (Agents Beats)Analyse de Logs (SIEM).Intégré (Kibana).
7.3 Cheat-sheet : Outils CLI SNMP (Linux)

Nécessite le paquet snmp (net-snmp-utils).

snmpget

Récupérer un seul OID.

# Usage: snmpget -v [version] -c [community] [IP] [OID]

# Récupérer le sysUpTime (temps écoulé)
$ snmpget -v2c -c public 192.168.1.1 1.3.6.1.2.1.1.3.0
snmpwalk

"Marcher" dans l'arbre OID (GETNEXT).

# Usage: snmpwalk -v [version] -c [community] [IP] [OID_de_départ]

# "Walker" toute la table des interfaces
$ snmpwalk -v2c -c public 192.168.1.1 1.3.6.1.2.1.2

# "Walker" la description des interfaces (ifDescr)
$ snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2
ifDescr.1 = STRING: "FastEthernet0/1"
ifDescr.2 = STRING: "FastEthernet0/2"