Métriques, journaux et métrologie réseau

La métrologie réseau mesure dans la durée ce qui circule sur le réseau (débits, taux d'utilisation des liens, pertes, latence, répartition du trafic par machine et par application) pour diagnostiquer, prévoir et dimensionner. Ce chapitre distingue d'abord les trois signaux de l'observabilité (métriques, journaux, traces) et fait la part entre la supervision et le SIEM, puis montre comment calculer un débit à partir des compteurs SNMP, lire un 95e centile, prévoir une saturation, et ce que NetFlow et sFlow ajoutent.

Métriques, journaux et traces

Une métrique dit qu'il se passe quelque chose (le temps de réponse a triplé), un journal dit ce qui s'est passé (la base a refusé des connexions), une trace dit où dans la chaîne. Les métriques coûtent peu à stocker et se prêtent aux seuils ; les journaux sont volumineux mais précis ; les traces concernent surtout les développeurs d'applications.

Ce qui relève du SIEM

Zabbix sait lire des journaux : l'élément log[/var/log/gestion/app.log,"ERROR|FATAL"] (agent actif) remonte chaque nouvelle ligne qui contient ERROR ou FATAL, logrt[] suit les fichiers qui tournent, eventlog[Application,,"Error"] lit le journal des événements Windows. C'est utile pour l'exploitation : une application qui écrit des erreurs, une sauvegarde qui échoue, un disque qui signale des secteurs défectueux.

La sécurité demande autre chose. Détecter une attaque, c'est rapprocher des événements de sources différentes (vingt échecs de connexion sur plusieurs comptes depuis la même adresse, suivis d'une réussite et de la création d'un compte administrateur), les comparer à des règles connues, les garder intacts plusieurs mois pour une enquête. C'est le rôle d'un SIEM (Security Information and Event Management) : il collecte les journaux de sécurité de toutes les machines, les normalise, les corrèle, alerte, et conserve les preuves. Chez Sorbier, ce rôle revient à Wazuh, une plateforme libre de détection (SIEM et XDR) : ses agents collectent les journaux de sécurité, contrôlent l'intégrité des fichiers et appliquent des règles de détection. Le cours Wazuh l'installe sur le même labo ; les événements d'Active Directory à surveiller sont listés dans Journaliser et détecter.

Les deux outils se complètent : Zabbix surveille aussi la santé du SIEM (son service, son disque, l'arrivée régulière des événements), et un incident de sécurité se voit souvent d'abord dans les métriques (un débit sortant anormal la nuit, un processeur à 100 % sur un serveur qui ne fait rien). La centralisation des journaux (syslog, rsyslog, transfert d'événements Windows), leur conservation et la corrélation sont traitées dans les cours Cybersécurité des infrastructures et Réponse à incident ; le transfert des événements Windows vers un collecteur, dans le cours Windows Server.

Calculer le débit d'une interface

Un switch ne donne pas un débit : il donne des compteurs. L'OID ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) est le nombre total d'octets reçus par un port depuis son démarrage. Le débit se calcule par différence entre deux mesures :

Exemple : le port montant de SW-ETAGE1 lit ifHCInOctets = 1 406 250 000 à 10 h 00, puis 3 906 250 000 à 10 h 05. La différence vaut 2 500 000 000 octets en 300 secondes : 2 500 000 000 × 8 ÷ 300 = 66,7 Mbit/s en entrée. Sur un lien à 1 Gbit/s, l'utilisation est de 6,7 %.

Dans Zabbix, c'est l'étape de prétraitement Change per second, suivie d'un multiplicateur × 8, qui fait ce calcul ; les modèles réseau le font pour chaque port découvert.

Moyenne, pic et 95e centile

Un graphique de débit sur un mois avec des points toutes les heures lisse les pics : la moyenne horaire de 40 % peut cacher dix minutes à 100 % chaque matin, pendant lesquelles les applications ralentissent. À l'inverse, le maximum est trompeur : un seul pic d'une minute pendant une sauvegarde suffit à le faire grimper.

Le 95e centile est le compromis de la métrologie réseau : on trie toutes les mesures du mois et on écarte les 5 % les plus hautes ; la plus grande valeur restante est le 95e centile. Avec une mesure toutes les 5 minutes sur 30 jours, on a 8 640 mesures : on écarte les 432 plus hautes, soit 36 heures de pics. Le résultat signifie : « 95 % du temps, le lien était à cette valeur ou en dessous ». Beaucoup d'opérateurs facturent les liens au 95e centile.

Exemple, sur 20 mesures du lien vers Marseille (en Mbit/s) : 12, 18, 25, 31, 22, 19, 95, 40, 38, 27, 33, 29, 41, 36, 24, 47, 30, 35, 26, 28.

• Triées : 12, 18, 19, 22, 24, 25, 26, 27, 28, 29, 30, 31, 33, 35, 36, 38, 40, 41, 47, 95.
• 5 % de 20 mesures, c'est 1 mesure : on écarte la plus haute (95).
• 95e centile = la 19e valeur = 47 Mbit/s. La moyenne vaut 32,8 Mbit/s, le maximum 95.

Le pic à 95 est un événement isolé ; le 95e centile à 47 montre la charge réelle aux heures chargées. Dans Zabbix, la fonction percentile(/R-MARSEILLE/net.if.in[…],30d,95) le calcule ; Grafana l'affiche avec une transformation ou un calcul de série.

Prévoir la saturation

La métrologie sert à voir venir. Zabbix extrapole une tendance avec deux fonctions :

• timeleft(/h/k,7d,90) : le temps estimé avant que l'élément atteigne 90, d'après la tendance des 7 derniers jours ;
• forecast(/h/k,7d,30d) : la valeur prévue dans 30 jours, d'après les 7 derniers jours.

Exemple : le volume de sauvegarde de srv-journaux fait 500 Go, 410 Go sont utilisés, et il grossit de 3 Go par jour depuis deux semaines. Il atteindra 90 % (450 Go) dans (450 − 410) ÷ 3 = 13,3 jours. Un déclencheur timeleft(/srv-journaux/vfs.fs.size[/srv/sauvegardes,pused],7d,90)<14d (le temps restant avant 90 % d'occupation est inférieur à 14 jours) alerte deux semaines à l'avance, bien avant le seuil classique de 90 % : le temps de commander un disque ou de revoir la rétention.

Ces fonctions supposent une croissance régulière (linéaire par défaut). Une purge, un nouveau service ou un changement de politique de sauvegarde cassent la tendance : relis la courbe avant de décider d'un achat.

NetFlow, sFlow et IPFIX : qui consomme le réseau ?

SNMP dit combien passe sur un port (66,7 Mbit/s), pas qui ni quoi. Pour répondre à « qui sature le lien de Marseille à 9 h ? », il faut des flux.

Un flux est un ensemble de paquets qui partagent les mêmes adresses source et destination, ports source et destination, et protocole. Un équipement exportateur (routeur, switch, pare-feu) résume chaque flux (début, fin, nombre d'octets et de paquets) et envoie ces résumés à un collecteur, qui les stocke et les présente : premiers émetteurs (top talkers), répartition par application, évolution dans le temps.

Sur pfSense, le paquet softflowd exporte des flux NetFlow vers un collecteur ; le paquet ntopng analyse le trafic directement sur le pare-feu et présente les principaux émetteurs et applications dans son interface web. Côté collecteur, nfdump et ses outils, ou ntopng sur un serveur, sont des choix libres courants.

La capture complète des paquets reste l'outil du diagnostic ponctuel, pas de la supervision permanente : le cours Réseaux fondamentaux montre comment lire une capture Wireshark couche par couche, et le diagnostic réseau les commandes de base.

Exercices

Exercice 1 sur 4 Débit et utilisation Réussi À revoir

Le port Gi0/0/0 de R-MARSEILLE (lien vers Lyon, 100 Mbit/s) donne ifHCOutOctets = 8 120 000 000 à 9 h 00 et 9 245 000 000 à 9 h 05.

1. Calcule le débit sortant moyen sur ces 5 minutes.
2. Calcule le taux d'utilisation du lien en sortie.
3. Le modèle déclenche une alerte au-dessus de 90 % ({$IF.UTIL.MAX}). Que fais-tu si ce taux revient chaque matin de 8 h 45 à 9 h 30 ?

Voir la réponseMasquer la réponse de l'exercice 1

1. Différence : 9 245 000 000 − 8 120 000 000 = 1 125 000 000 octets. Débit : 1 125 000 000 × 8 ÷ 300 = 30 Mbit/s.
2. 30 ÷ 100 × 100 = 30 %. Pas d'alerte à ce moment-là.
3. Un dépassement quotidien et prévisible n'est pas un incident à traiter chaque matin, c'est une question de capacité : identifier ce qui consomme à cette heure (NetFlow : synchronisation de fichiers, mises à jour, sauvegarde mal planifiée), décaler ce qui peut l'être (planifier les mises à jour la nuit, limiter un flux par la qualité de service), et si le besoin est légitime, chiffrer l'augmentation du lien à partir du 95e centile mesuré sur plusieurs semaines.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Le compteur qui boucle Réussi À revoir

Un vieux switch ne fournit que ifInOctets (32 bits) sur un port à 1 Gbit/s. Zabbix l'interroge toutes les 60 secondes. Le graphique montre des débits incohérents, parfois très bas alors que le port est chargé.

1. Explique le phénomène.
2. Au-delà de quel débit moyen le problème apparaît-il avec une mesure par minute ?
3. Quelles solutions proposes-tu ?

Voir la réponseMasquer la réponse de l'exercice 2

1. Le compteur 32 bits revient à zéro après 2³² = 4 294 967 296 octets. Si plus de 4,29 Go passent entre deux mesures, il a fait un tour complet (ou plus) : la différence calculée est fausse, trop basse.
2. 4 294 967 296 octets en 60 secondes : 4 294 967 296 × 8 ÷ 60 ≈ 573 Mbit/s. Au-delà de ce débit moyen sur une minute, un tour complet est possible entre deux mesures. (À 1 Gbit/s plein, le tour prend 34,4 secondes.)
3. Utiliser les compteurs 64 bits ifHCInOctets si l'équipement les fournit (SNMP v2c ou v3 obligatoire, la v1 ne les connaît pas) ; sinon interroger plus souvent (toutes les 20 secondes, sans descendre en dessous de ce qui charge l'équipement) ; à terme, remplacer l'équipement.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Le 95e centile Réussi À revoir

Voici 20 mesures du débit entrant du lien Internet du siège, en Mbit/s : 210, 185, 240, 198, 905, 230, 260, 175, 220, 245, 190, 300, 255, 215, 870, 205, 235, 225, 250, 265.

1. Calcule la moyenne, le maximum et le 95e centile.
2. Lequel de ces trois chiffres utiliserais-tu pour dimensionner le lien, et pourquoi ?

Voir la réponseMasquer la réponse de l'exercice 3

1. Somme : 5 878, moyenne 293,9 Mbit/s. Maximum : 905. Triées : 175, 185, 190, 198, 205, 210, 215, 220, 225, 230, 235, 240, 245, 250, 255, 260, 265, 300, 870, 905. On écarte 5 % de 20 mesures, soit 1 : le 95e centile est la 19e valeur, 870 Mbit/s.
2. Ici, le 95e centile est tiré vers le haut parce que deux mesures sur vingt (10 %) sont des pics : le centile n'en écarte qu'une. Cela montre qu'il ne s'agit pas d'un pic isolé mais d'un phénomène récurrent (deux périodes à près de 900 Mbit/s) : il faut l'expliquer (sauvegarde vers l'extérieur, mise à jour massive) avant de dimensionner. Sur un vrai mois de mesures (8 640 points), le 95e centile reste l'indicateur de référence : il ignore 36 heures de pics, tout en montrant la charge des heures chargées. La moyenne sous-estime le besoin, le maximum le surestime.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Supervision ou SIEM ? Réussi À revoir

Pour chaque besoin, dis s'il relève de Zabbix, du SIEM ou des deux, et pourquoi.

1. Être alerté quand le service de transfert d'événements de srv-collecte s'arrête.
2. Détecter une connexion réussie d'un compte d'administration à 3 h du matin depuis un poste du VLAN des visiteurs.
3. Savoir dans combien de jours le disque du serveur de journaux sera plein.
4. Être prévenu d'un débit sortant inhabituel de 800 Mbit/s vers Internet depuis srv-fichiers, un dimanche.

Voir la réponseMasquer la réponse de l'exercice 4

1. Zabbix : un service arrêté est un état d'exploitation (service.info sur srv-collecte). Le SIEM s'apercevrait seulement qu'il ne reçoit plus d'événements.
2. SIEM : il faut rapprocher un événement d'authentification (sur le contrôleur de domaine), un compte privilégié, une heure et une adresse source ; c'est une règle de corrélation de sécurité.
3. Zabbix : une prévision de capacité (timeleft) sur un élément d'espace disque.
4. Les deux : Zabbix voit l'anomalie de débit (un seuil, ou une comparaison avec la semaine précédente) et alerte l'exploitation ; c'est peut-être une exfiltration de données, que le SIEM et les journaux de srv-fichiers et du pare-feu permettront de confirmer ou d'écarter. Les flux NetFlow diront vers quelle destination.

Tu avais trouvé ?

Oui, j'avais bonPas encore