Logs, monitoring et alerting
Définition
La supervision réseau repose sur trois piliers complémentaires :
- Logs (journaux) : enregistrements horodatés des événements générés par les équipements et systèmes (connexion, erreur, changement de configuration…).
- Monitoring (surveillance) : collecte et visualisation continue de métriques (utilisation CPU, bande passante, latence, état des interfaces…).
- Alerting (alertes) : notifications automatiques déclenchées lorsqu'une métrique dépasse un seuil ou qu'un événement critique survient.
Contexte
Une supervision proactive permet de détecter les dégradations avant qu'elles n'impactent les utilisateurs, d'accélérer le diagnostic lors d'incidents, et de fournir des données historiques pour le capacity planning. La certification CCST attend du candidat une compréhension des protocoles de supervision et des bonnes pratiques associées.
Détails techniques
Syslog — le standard de journalisation
Syslog (RFC 5424) est le protocole universel de journalisation réseau. Les messages sont envoyés en UDP (port 514) ou TCP (port 514 ou 6514 avec TLS) vers un serveur Syslog central.
| Niveau (Severity) | Mot-clé | Description |
|---|---|---|
| 0 | Emergency | Système inutilisable |
| 1 | Alert | Action immédiate requise |
| 2 | Critical | Condition critique |
| 3 | Error | Condition d'erreur |
| 4 | Warning | Avertissement |
| 5 | Notice | Événement normal mais significatif |
| 6 | Informational | Message d'information |
| 7 | Debug | Messages de débogage (très verbeux) |
Configuration Cisco :
logging host 10.1.0.200 ! Serveur Syslog central
logging trap informational ! Envoyer les niveaux 0-6
logging source-interface Loopback0 ! Source stable pour les logs
service timestamps log datetime msec ! Horodatage précis
SNMP — Simple Network Management Protocol
SNMP permet de lire (polling) et modifier les paramètres des équipements réseau via une structure hiérarchique (MIB — Management Information Base).
| Version | Sécurité | Usage |
|---|---|---|
| SNMPv1 | Community string en clair | Obsolète |
| SNMPv2c | Community string en clair, + bulk operations | Encore répandu, mais non sécurisé |
| SNMPv3 | Authentification + chiffrement (SHA, AES) | Recommandé pour la production |
| Opération | Description |
|---|---|
| GET | Lire une valeur (ex : utilisation CPU) |
| GET-NEXT | Parcourir séquentiellement la MIB |
| GET-BULK | Récupérer plusieurs valeurs en une requête (v2c/v3) |
| SET | Modifier une valeur (ex : activer une interface) |
| TRAP | Notification spontanée de l'équipement vers le serveur (ex : interface down) |
| INFORM | Comme TRAP mais avec acquittement |
NetFlow / IPFIX — analyse des flux
NetFlow (Cisco) et IPFIX (standard IETF) exportent des métadonnées de flux (pas le contenu des paquets) vers un collecteur :
| Champ | Description |
|---|---|
| IP source / destination | Endpoints du flux |
| Port source / destination | Application concernée |
| Protocole | TCP, UDP, ICMP… |
| Octets / paquets | Volume du flux |
| Timestamps | Début et fin du flux |
| Interface entrée / sortie | Localisation dans la topologie |
Cas d'usage : capacity planning, détection de trafic anormal (DDoS, exfiltration de données), justification de l'investissement QoS.
Outils de monitoring courants
| Outil | Type | Description |
|---|---|---|
| Nagios / Icinga | Polling SNMP + scripts | Supervision classique, alertes |
| Zabbix | Polling + agents | Supervision infrastructure complète |
| Prometheus + Grafana | Pull metrics + dashboards | Métriques time-series, très populaire |
| ELK Stack (Elasticsearch, Logstash, Kibana) | Logs | Centralisation, recherche et visualisation des logs |
| Splunk | Logs + SIEM | Analyse avancée, corrélation de sécurité |
| SolarWinds / PRTG | Multi-protocole | Supervision réseau tout-en-un |
| Cisco DNA Center | Controller | Supervision Cisco intégrée, analytics |
Bonnes pratiques d'alerting
| Pratique | Description |
|---|---|
| Seuils dynamiques | Basés sur la baseline historique plutôt que des valeurs fixes |
| Escalade | Email → SMS → appel téléphonique si non acquitté |
| Corrélation | Regrouper les alertes liées (ex : 20 interfaces down = un switch, pas 20 problèmes) |
| Suppression du bruit | Filtrer les alertes de maintenance planifiée |
| Rétention | Conserver les logs au moins 90 jours (exigence réglementaire courante) |
| NTP | Synchroniser l'horloge de tous les équipements pour des timestamps cohérents |
Exemple concret
Scénario : un fournisseur d'accès Internet (FAI) supervise 500 routeurs Cisco.
- Syslog : tous les routeurs envoient leurs logs vers un serveur rsyslog central avec un niveau minimal
informational(0-6). Les logs sont ingérés dans ELK pour la recherche. - SNMP : Zabbix interroge chaque routeur toutes les 60 secondes via SNMPv3 (CPU, RAM, bande passante par interface, état des interfaces).
- NetFlow : chaque routeur exporte les flux NetFlow vers un collecteur nfsen. L'équipe analyse les top-talkers et détecte les anomalies.
- Alerting :
- Interface down → alerte SMS immédiate à l'équipe NOC.
- CPU > 80 % pendant 5 minutes → alerte email.
- Trafic NetFlow anormal (volume 10x la baseline) → alerte SIEM pour investigation de sécurité.
- Corrélation : un matin, 15 interfaces passent down simultanément. Zabbix corrèle et affiche une seule alerte : « Core switch Site-A — probable panne ». L'équipe intervient immédiatement sur le bon équipement au lieu de traiter 15 tickets individuels.