In molte infrastrutture il monitoraggio viene affrontato troppo tardi, quasi come un accessorio da aggiungere quando iniziano i problemi. Si installano gli apparati, si porta in esercizio la rete, si verifica che utenti e servizi riescano a collegarsi, e solo dopo si pensa a come leggere davvero ciò che sta accadendo. Questo approccio produce un effetto molto prevedibile: la rete funziona finché tutto resta vicino allo stato nominale, ma quando emergono saturazioni, errori intermittenti, instabilità di uplink, latenze anomale o degradi progressivi, il team tecnico si trova a rincorrere sintomi invece di interpretare dati. In una rete di edificio o di campus, dove convivono utenti, Wi-Fi, sistemi IP, sicurezza, servizi di building e collegamenti tra armadi o tra building, questa debolezza non è marginale. Diventa un costo operativo continuo.
Monitoring, logging e baseline non sono tre temi separati. Costituiscono una stessa disciplina di osservabilità della rete. Il monitoring raccoglie indicatori numerici e stati operativi; il logging conserva eventi, errori, cambi di stato e messaggi di sistema; la baseline trasforma questi dati in una misura comparabile del comportamento normale dell’infrastruttura, così da poter riconoscere quando la rete si sta allontanando dalle sue condizioni corrette. È questo passaggio che consente di vedere il degrado prima che si manifesti come fermo operativo, come chiamata urgente o come contestazione da parte dell’utente finale. Il framework IETF sulla network telemetry descrive proprio questo scenario: telemetria significa raccolta, correlazione e utilizzo dei dati di rete per migliorare gestione ed efficienza operativa.
La prima distinzione da fissare riguarda la differenza tra rete funzionante e rete osservabile. Una rete può essere apparentemente funzionante perché gli utenti navigano, i server rispondono e i servizi principali restano disponibili. Questo, però, non dice nulla sulla qualità strutturale del comportamento interno. Una dorsale può essere vicina alla saturazione in alcune fasce orarie, un uplink può generare errori crescenti, un access switch può avere CPU elevata, un dominio Wi-Fi può mostrare pattern anomali, un trunk può essere configurato correttamente ma trasportare molto più traffico del previsto. Senza osservabilità, questi segnali restano invisibili fino a quando non si trasformano in guasto percepito. La baseline, secondo la documentazione Cisco sulle reti ad alta disponibilità, serve esattamente a questo: determinare lo stato corrente della rete, confrontarlo con linee guida di prestazione e impostare soglie significative invece di allarmi casuali o predefiniti.
Per costruire osservabilità reale occorre partire dai dati giusti. Il monitoraggio di rete non coincide con il semplice “ping” verso gli apparati né con una schermata che mostra dispositivi verdi o rossi. Serve raccogliere almeno quattro famiglie di informazioni. La prima riguarda disponibilità e stato degli apparati: raggiungibilità, interfacce up/down, alimentazioni, stato dei moduli, ridondanze, errori di link. La seconda riguarda le risorse interne: CPU, memoria, tabelle, code, temperature, buffer, stato degli stack o dei cluster. La terza riguarda il traffico: utilizzo delle interfacce, pattern temporali, top talkers, volumi per direzione, eventuali anomalie rispetto alle abitudini della rete. La quarta riguarda gli eventi: autenticazioni fallite, cambi di ruolo, rinegoziazioni, errori di spanning tree, flap di interfaccia, failover, messaggi di sicurezza e attività amministrative. È l’insieme di questi strati a rendere una rete leggibile.
Nel modello classico, una parte rilevante di questi dati passa attraverso SNMP. L’architettura SNMP definita dall’IETF è modulare e comprende motore, sicurezza, access control e gestione delle informazioni, proprio per consentire raccolta strutturata dei dati di gestione dagli apparati di rete. Questo significa che SNMP non è solo un protocollo “vecchio ma ancora usato”, come viene spesso liquidato superficialmente; è ancora uno dei canali fondamentali per estrarre metriche da switch, router e molti dispositivi di infrastruttura. Resta però vero che il suo valore dipende da quali oggetti vengono letti, con quale frequenza, con quale criterio e in quale contesto interpretativo. Polling senza metodo genera solo quantità di dati. Polling coerente con una baseline genera indicatori utili.
Accanto alle metriche, il logging ha un ruolo diverso e complementare. Il syslog, standardizzato dall’RFC 5424, definisce il formato e la struttura dei messaggi di log, permettendo di raccogliere in modo coerente eventi provenienti da dispositivi e sistemi differenti. Il suo valore non è soltanto archivistico. I log permettono di ricostruire sequenze: quando un link ha iniziato a flappare, quando un apparato ha cambiato stato, quando un servizio si è riavviato, quando una configurazione è stata modificata, quando un sistema ha registrato errori ripetitivi o condizioni anomale. Nelle reti complesse, il degrado raramente compare come un singolo evento isolato. Più spesso emerge come serie di piccoli segnali dispersi. Il logging è ciò che consente di dare continuità temporale a questi segnali.
Qui entra in gioco una regola spesso ignorata: i log devono essere centralizzati, ordinati e conservati con una logica di consultazione. Se ogni apparato trattiene i propri messaggi in locale, il valore diagnostico si riduce drasticamente. Quando invece gli eventi convergono verso una raccolta centrale, diventano confrontabili. Un flap su un uplink può essere letto insieme a un cambio STP, a un failover di gateway, a un picco di CPU su uno switch o a un aumento di errori su un’interfaccia WAN. È questa correlazione che distingue il semplice accumulo di log dalla vera capacità di analisi operativa.
La baseline rappresenta il passaggio più maturo di tutto il sistema. Senza baseline, ogni soglia è arbitraria. La documentazione Cisco sul baselining insiste su questo punto in modo molto chiaro: le soglie non dovrebbero essere attivate prima di aver studiato il comportamento reale della rete, altrimenti si generano allarmi inutili oppure, al contrario, si lasciano passare condizioni di degrado che non vengono riconosciute in tempo. La baseline serve a capire come si comportano CPU, memoria, link, errori, code e volumi di traffico durante giornate normali, picchi ricorrenti, cicli settimanali e variazioni stagionali. Solo conoscendo questa fisiologia si possono costruire soglie che abbiano senso.
Questo ha implicazioni molto concrete. Un uplink che raggiunge il 70% di utilizzo può essere perfettamente normale in una fascia oraria prevista, oppure può essere un segnale serio di futura saturazione se la baseline storica mostrava valori molto più bassi. Una CPU al 60% può essere fisiologica su un apparato in determinate condizioni, o del tutto anomala su uno switch access che normalmente lavora al 15%. Un picco di broadcast può non essere un problema se resta circoscritto e sporadico, oppure può rivelare l’inizio di una propagazione indesiderata se compare con regolarità in uno specifico dominio. La baseline non rende la rete solo “monitorata”; la rende interpretabile.
Per questo il monitoring non dovrebbe partire da dashboard spettacolari ma da una matrice di priorità. In una rete di edificio o di campus i primi punti da osservare sono quasi sempre il core, la distribuzione, gli uplink di building, le dorsali ottiche, i gateway di VLAN critiche, gli access switch che aggregano aree ad alta densità, gli apparati a supporto del Wi-Fi, i nodi che sostengono sicurezza fisica o servizi di building e tutti i collegamenti il cui degrado si propagherebbe rapidamente a più domini di servizio. Cisco, nella propria documentazione di baseline, suggerisce proprio di partire dalla parte più stabile e critica della rete, cioè il core, perché è lì che si concentrano dipendenze e necessità di continuità.
Un altro tema centrale riguarda il traffico. Le sole metriche di interfaccia spesso non bastano. Per capire davvero dove sta andando la rete serve una visione di flusso. Cisco, nelle proprie pagine di network monitoring, include esplicitamente NetFlow e RMON tra i sottoprotocolli e strumenti di osservazione della rete. Questo è importante perché permette di superare una lettura puramente volumetrica: non basta sapere che una porta è occupata all’80%, serve anche capire da chi, verso dove, con quali pattern temporali e con quale impatto sugli altri servizi. In contesti con Wi-Fi, videosorveglianza, backup, traffico verso cloud e sistemi di edificio, la differenza tra volume e composizione del traffico è spesso ciò che consente di identificare il problema reale.
Naturalmente, più la raccolta dati cresce, più cresce il rischio opposto: raccogliere tutto senza riuscire a leggere nulla. Questo è uno degli errori più frequenti. Si abilita SNMP su tutto, si centralizzano i syslog, si attivano dashboard, si collezionano flussi, ma senza un modello di priorità, una tassonomia dei dispositivi, una baseline iniziale e una logica di soglia. Il risultato è un ambiente rumoroso che genera attenzione frammentata. Non aiuta il troubleshooting, anzi lo complica. Il principio corretto è l’opposto: partire da pochi indicatori critici, associarli a un comportamento atteso, costruire una baseline e solo dopo estendere il perimetro del monitoraggio.
Nelle reti orientate a continuità operativa, un buon sistema di monitoring e logging produce almeno quattro risultati tangibili. Il primo è la diagnosi più rapida, perché riduce il tempo perso a capire se il problema è locale, distribuito, intermittente o strutturale. Il secondo è la capacità predittiva, perché rende visibili trend di crescita, saturazioni ricorrenti e nodi che stanno diventando critici. Il terzo è la qualità del cambiamento, perché ogni modifica di configurazione può essere letta nel suo effetto operativo e confrontata con lo storico. Il quarto è la qualità contrattuale e documentale, perché una rete osservata e misurata è anche una rete più facile da difendere, da discutere e da far evolvere con criteri tecnici chiari.
Per questo, quando si progetta una rete di edificio o campus, monitoring, logging e baseline non dovrebbero mai essere trattati come un livello secondario. Sono parte dell’architettura. Una rete senza osservabilità resta dipendente dall’intuito dei singoli tecnici. Una rete osservabile, invece, costruisce metodo. Rende leggibili i segnali deboli, separa le anomalie occasionali dai degradi veri, consente di impostare soglie sensate e crea la base per decisioni tecniche più solide nel tempo.
Conclusione
Vedere il degrado prima del fermo operativo non è una questione di fortuna né di sensibilità personale. È il risultato di un sistema costruito con dati coerenti, eventi centralizzati e baseline ben impostata. SNMP fornisce metriche di gestione strutturate, il syslog restituisce la sequenza degli eventi, la network telemetry amplia la capacità di insight, e la baseline trasforma i numeri in comportamento interpretabile. Quando questi elementi lavorano insieme, la rete smette di essere un insieme opaco di apparati e diventa un’infrastruttura osservabile, governabile e molto più stabile nella vita quotidiana.
