Anche il vostro monitoraggio è un sistema: testate il percorso, non il dashboard

Uno schermo di monitoraggio silenzioso ha due significati possibili: va tutto bene, oppure il monitoraggio non vede. Dal solo schermo non potete dire quale. Ogni stack di monitoraggio è una catena di dispositivi, agent, collector, regole e canali di notifica, e ogni anello può rompersi senza sollevare alcun allarme proprio. Questo articolo parla di come dimostrare che la catena funziona, di routine, prima del giorno in cui ne avrete bisogno.

Il silenzio non è una prova

La maggior parte dei design di monitoraggio controlla con cura le cose monitorate e dà per scontato il monitoraggio stesso. Uno switch è configurato per inviare syslog, quindi si presume che i suoi log arrivino. Una regola di allarme esiste, quindi si presume che una notifica raggiunga qualcuno. Un job di backup è schedulato, quindi si presume che una copia della configurazione esista. Nessuna di quelle supposizioni è una misurazione.

I punti in cui questa catena tipicamente si rompe sono banali: un'interfaccia sorgente o un'istanza di routing per il logging che non raggiunge il collector, una regola di firewall nel mezzo, un input del collector riconfigurato, un'integrazione di notifica con il token scaduto, un filtro di severità degli allarmi che esclude in silenzio il tipo di evento che vi interessa. Nessuno di questi fa sembrare un dispositivo malsano dalla sua riga di comando.

Controllo uno: ogni dispositivo viene davvero ascoltato?

La vista del dispositivo (show logging elenca un server e dice che è abilitato) è un'affermazione. La vista del collector è la prova. Rovesciate la domanda e chiedete al collector: quando ogni dispositivo ha inviato qualcosa per l'ultima volta?

In Graylog, una ricerca raggruppata per sorgente sull'ultimo giorno mostra ogni dispositivo che ha parlato; confrontate quella lista con il vostro inventario, e tutto ciò che manca è il vostro riscontro. Un semplice test end-to-end dal dispositivo stesso elimina ogni dubbio. Su Cisco IOS e NX-OS, generate un messaggio innocuo e cercatelo sul collector entro pochi secondi:

send log 6 "monitoring path test from this device"

Su un host Linux:

logger -p user.notice "monitoring path test from $(hostname)"

Se il messaggio non compare, seguite il percorso in ordine: indirizzo sorgente e istanza di routing usati per il logging, raggiungibilità del collector da quella sorgente, eventuali firewall nel mezzo, poi l'input del collector e le regole degli stream.

Fate lo stesso confronto per i backup delle configurazioni. Un dispositivo la cui ultima configurazione salvata ha settimane ha un percorso di backup rotto, anche se nulla è mai andato in errore.

Controllo due: un allarme raggiunge un essere umano?

Fate scattare di proposito un allarme reale attraverso l'intera catena: un trigger di prova, un item fittizio che supera una soglia, o una firma di log che iniettate. Confermate che la notifica arrivi nel canale che i vostri ingegneri leggono davvero, con la severità giusta, entro il tempo che vi aspettate. Fatelo dopo qualsiasi modifica alla piattaforma di monitoraggio stessa, e a calendario anche quando nulla è cambiato, perché i token scadono e le integrazioni derivano.

In Zabbix bastano un item di prova su un host monitorato più un trigger alla severità per cui notificate. Spingete un valore e guardatelo viaggiare:

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Poi confermate tre cose: il problema è comparso, la notifica è stata consegnata, e il ripristino è stato consegnato quando avete azzerato il valore.

Controllo tre: le severità sono oneste?

Rivedete quali eventi raggiungono una persona e quali no. Una lista breve ed esplicita di firme che notificano sempre (neighbour di routing giù, link giù, BFD giù, errori crittografici VPN, guasti di alimentazione, ventole e temperatura, errori della rete di storage, tabelle di stato del firewall vicine al limite) è più facile da difendere di una soglia che qualcuno ha impostato anni fa.

Qui una seconda opinione aiuta. Le regole filtrano prima il rumore noto, poi tutto ciò che resta viene analizzato in tempo reale da modelli AI sulle nostre GPU NVIDIA A100, dentro il nostro datacenter. L'analisi legge un allarme insieme alla sua storia recente e agli eventi correlati e offre agli ingegneri una seconda opinione su cosa sta probabilmente succedendo. I dati degli allarmi non lasciano mai la nostra infrastruttura, e la decisione resta all'ingegnere.

Controllo quattro: guardate dall'esterno

Ogni vista dall'interno della vostra rete condivide i punti ciechi della vostra rete. Una piattaforma di misurazione globale come RIPE Atlas, con un anchor o dei probe che misurano verso di voi, mostra come i luoghi reali di internet vi raggiungono: latenza, perdita e cambi di percorso. Quando un carrier fa manutenzione, la vista dall'esterno vi dice quanto ha impiegato la riconvergenza e se qualcuno avrebbe potuto accorgersene, cosa che nessun contatore interno può fare.

Per i circuiti privati, un probe dedicato a ogni capo che misura latenza, jitter e throughput in entrambe le direzioni ogni minuto, conservato in modo permanente, trasforma ogni conversazione con un carrier da opinione in dati. Escludete il traffico del probe dalle statistiche del circuito stesso, così la prova resta pulita.

Controllo cinque: ispezionate quando non c'è nulla che non va

Eseguite ispezioni di salute in sola lettura a calendario, non solo dopo un allarme. Condizioni ambientali, stato del routing e dell'overlay, coerenza della ridondanza tra coppie, livelli delle ottiche e contatori di errore delle interfacce cambiano lentamente, e il cambiamento lento è esattamente ciò che gli allarmi a soglia non vedono. Un'ottica che deriva verso il suo limite di luce bassa è una sostituzione tranquilla questa settimana o un disservizio il mese prossimo.

La vostra checklist di autodiagnosi del monitoraggio

• Potete elencare ogni dispositivo che non ha inviato un log nell'ultimo giorno?
• Potete elencare ogni dispositivo la cui configurazione salvata è più vecchia della sua ultima modifica?
• Quando avete fatto scattare per l'ultima volta un allarme reale end to end, ed è arrivato?
• Le severità che notificano una persona corrispondono a una lista scritta?
• Vedete la vostra rete dall'esterno, in modo continuo?
• Ispezionate quando non si sa di nulla che non va?

Monitoriamo la nostra rete con Zabbix, Graylog, Observium e un anchor RIPE Atlas, ed eseguiamo questi controlli su di essa a calendario. Se volete un fornitore che risponda con misurazioni, o aiuto per testare la vostra catena, parlate con noi.

Parla con un ingegnere

Related (rows[1])

Correlati: Monitoraggio della rete ed evidenze · Come cambiamo le cose: disciplina delle modifiche di rete · La nostra rete: due ASN, molti carrier, peering