Monitoraggio con SNMP: Storie dall'inferno

Chi monitora la propria rete con SNMP beneficia del fatto che molti produttori supportano il Simple Network Management Protocol sui loro dispositivi. Da oltre 30 anni, SNMP è diventato lo standard de facto per il monitoraggio delle reti, e per questo quasi tutti i produttori hanno integrato un agente SNMP nei loro componenti. Tuttavia, non tutti gestiscono questa implementazione in modo conforme alle specifiche dello standard.

Dal momento che molti utenti di Checkmk utilizzano SNMP per monitorare i propri ambienti di rete, sappiamo per esperienza diretta quanto siano purtroppo frequenti le implementazioni non corrette da parte di alcuni produttori. In questo articolo vogliamo condividere alcuni esempi tipici di implementazioni SNMP difettose, basati sulla nostra esperienza sul campo.

SNMP fornisce dati errati

Se gli sviluppatori di un produttore non implementano correttamente il protocollo SNMP, può accadere che l'agente fornisca dati confusi o addirittura errati, non sia performante, non sia conforme allo standard SNMP o semplicemente non funzioni. Questo crea diversi problemi per il monitoraggio dell'ambiente di rete, in quanto è più difficile ottenere i dati richiesti.

Con Checkmk, spesso è possibile ottenere le informazioni di monitoraggio necessarie utilizzando diverse MIB standard, come Host-Resources e UCD. Tuttavia, questo può diventare problematico quando, ad esempio, entrambe le MIB restituiscono valori differenti per la memoria principale. In questi casi, può darsi che una delle due riporti un dato errato mentre l’altra fornisce quello corretto. In teoria, però, è anche possibile che entrambe forniscano valori non attendibili. Se vuoi saperne di più su come funzionino gli OID e le MIB, leggi il nostro primo articolo sul monitoraggio della rete con SNMP.

Quando un agente SNMP fornisce dati contraddittori o addirittura errati, l’amministratore è costretto a procedere per tentativi per capire quali valori siano affidabili e quali no, escludendo poi dal monitoraggio quelli scorretti. Il tutto può sembrare piuttosto complicato. La buona notizia è che Checkmk spesso riconosce automaticamente i valori errati e li ignora, semplificando così il lavoro. Questo è possibile grazie al modo in cui Checkmk gestisce il monitoraggio SNMP:

Quando il monitoraggio avviene tramite SNMP, Checkmk esegue un'estrazione completa di tutti i dati SNMP (SNMP walk) durante la scoperta del servizio e poi cerca le informazioni interessanti. Dato che per alcuni dispositivi ciò richiederebbe diverse ore, Checkmk richiama solo i primi due OID, sysDescr e sysObjectID. Il sysDescr è la descrizione del dispositivo, che il produttore ha definito nel firmware. Questo testo è importante per consentire a Checkmk di rilevare automaticamente i servizi. A seconda del dispositivo rilevato, vengono effettuate ulteriori interrogazioni per determinare quali degli oltre 1.000 plug-in di controllo SNMP forniti con Checkmk siano adatti al dispositivo. Il risultato della scansione di uno switch, ad esempio, potrebbe essere il seguente:

SNMP scan found hr_mem if64 ucd_mem mgmt_snmp_uptime snmp_info snmp_uptime
SNMP filtered check plugin names hr_mem if64 snmp_info snmp_uptime

Come si può notare, Checkmk ha in parte trovato dati rilevanti in diverse posizioni dell'albero OID (ad esempio mgmt_snmp_info e snmp_uptime ), consentendo di filtrare l'elenco finale dei controlli corrispondenti. Se è già noto che uno di questi OID trovati restituisca valori errati, Checkmk li elimina direttamente. In questo esempio, Checkmk ha scelto hr_mem perché è noto che questo dispositivo fornisce dati errati in ucd_mem.

Nella fase successiva, viene eseguito il riconoscimento del servizio vero e proprio. I plug-in di controllo identificati nella fase di scansione utilizzano ora richieste SNMP mirate per recuperare i dati di cui hanno bisogno. In base ai valori ricevuti, determinano i servizi da monitorare. Questa è la cosiddetta "fase di scoperta".

Nota: Per ragioni storiche, la funzione Checkmk sottostante è ancora chiamata inventory_function nel codice. Con l'introduzione dell'inventario hardware e software, abbiamo cambiato la visualizzazione nella GUI in Check_MK Discovery per evitare qualsiasi malinteso.

La terza e ultima fase è la cosiddetta fase di controllo. Viene eseguita a ogni ciclo di controllo e recupera gli OID che Checkmk ha trovato nella fase di scoperta.

Mele o pere? Quando i dati SNMP non tornano

Come abbiamo visto, può capitare che i dispositivi restituiscano uno o più valori errati. Ma questo non è l’unico tipo di problema possibile. Le unità di misura non definite correttamente – o dichiarate in modo impreciso – sono spesso fonte di discussioni animate tra i nostri sviluppatori, anche durante le pause caffè. Non è raro, ad esempio, che un produttore indichi come unità i gradi Celsius, mentre l’implementazione SNMP riporti nell’OID valori in Fahrenheit.

Una volta ci siamo persino imbattuti in una soluzione particolarmente “creativa”: la documentazione parlava chiaramente di gradi Celsius, ma da nessuna parte era specificato che il valore restituito rappresentava in realtà 1⁄10 di grado Celsius.

Anche una documentazione carente o un’implementazione “creativa” da parte del produttore possono creare ulteriore confusione. Ad esempio, usare il valore “0°C” per indicare che un sensore è guasto o non disponibile può facilmente generare fraintendimenti nella misurazione della temperatura ambiente, con il rischio, nei casi peggiori, di causare errori gravi.

Questi due esempi dimostrano che per l'utente può essere ingannevole affidarsi ciecamente ai dati interrogati tramite SNMP. Dimostra inoltre che il monitoraggio SNMP richiede il necessario know-how e che non è possibile ricavare una formula generalmente valida per ogni dispositivo SNMP. Al contrario, ogni dispositivo deve essere considerato singolarmente. Solo con la necessaria conoscenza del contesto è possibile interpretare correttamente i dati raccolti.

"Che giorno è oggi?" - "Febbraio!".

Non sorprende che anche l’implementazione del protocollo SNMP sia soggetta ai classici errori di programmazione. Di conseguenza, molti degli errori comuni nel software si ritrovano anche nelle implementazioni SNMP. Un esempio emblematico riguarda il formato della data: invece di seguire lo standard ISO, spesso si utilizzano diverse varianti locali, come AAAAMMGG, GGMMYYYY o semplicemente AAAA. Ad esempio, la data 05022020 può essere interpretata sia come 5 febbraio 2020 che come 2 maggio 2020. Se l’anno è indicato con due cifre, il formato 050220 potrebbe significare 20 febbraio 2005.

Questo significa che, in questi casi, tocca all’utente o allo sviluppatore del controllo occuparsi dei dettagli. Ad esempio, ci è capitato che un produttore utilizzasse tre cifre per il giorno nel formato data dello stack SNMP: “001” indicava così il primo giorno di ogni mese. Certo, tecnicamente è possibile farlo, ma davvero dovrebbe essere così…?

Ci vediamo tra un minuto...

Quando si parla di monitoraggio della rete con SNMP, si parla spesso del carico costante causato dal polling SNMP, ovvero il polling dei dati in un determinato intervallo di tempo, sui dispositivi. In passato, quando i sistemi di monitoraggio non erano così potenti e potevano interrogare i dati solo a intervalli di alcuni minuti, questo non aveva un effetto così grande sui componenti della rete. Nel frattempo, però, le soluzioni di monitoraggio sono diventate molto più potenti.

Di default, Checkmk esegue il polling dei dispositivi ogni minuto. Come spiegato in questo articolo, rileva automaticamente gli OID necessari per i servizi da monitorare. Grazie a questo processo efficiente, Checkmk mantiene il carico sui dispositivi il più basso possibile. Fortunatamente, la maggior parte dei dispositivi moderni gestisce senza problemi un intervallo di polling di un minuto. Tuttavia, l’esperienza dimostra che dispositivi più datati o stack di switch di grandi dimensioni possono avvicinarsi ai loro limiti prestazionali.

L'allergia all'OID

Di tanto in tanto può accadere che i dispositivi abbiano una "reazione allergica" alla sequenza di OID interrogata in un controllo. Ad esempio, se gli OID vengono interrogati con un snmpbulkget con una dimensione di massa di 10, può accadere che lo stack SNMP si blocchi a un certo punto e non restituisca alcun valore, o solo valori incompleti. Nel prossimo articolo esamineremo più da vicino questo problema e spiegheremo come risolverlo. Per gli sviluppatori di check, ad esempio, una soluzione potrebbe essere quella di cambiare l'ordine degli OID interrogati per evitare che lo stack SNMP si blocchi.

A volte può succedere che una MIB non sia retrocompatibile, anche se dovrebbe esserlo di default. Questo diventa un problema quando il firmware cambia l’implementazione degli OID. A seconda della versione del firmware installata sul dispositivo di rete, è quindi fondamentale sapere sotto quale OID si trova il valore che si sta cercando.

Odissea UDP

Non sono solo i polling SNMP a presentare limiti e svantaggi: anche le trap SNMP spesso non funzionano come promesso. Un’implementazione difettosa può impedire l’attivazione automatica di una trap, anche quando si è verificato un evento.

Questo problema si acuisce quando un produttore pubblicizza il supporto SNMP sul dispositivo, ma in realtà integra solo trap basate su eventi, escludendo quindi il polling SNMP per il monitoraggio dei dati. Unito agli altri svantaggi delle trap, ciò può creare notevoli difficoltà nel monitoraggio della rete.

Inoltre, il monitoraggio tramite trap è molto più soggetto a errori rispetto a quello basato su richieste SNMP attive. Questo perché le trap vengono inviate come pacchetti UDP, che possono andare persi senza che il destinatario ne venga informato, poiché non esiste una verifica della ricezione. Di conseguenza, il ricevente potrebbe non sapere nemmeno che una notifica è stata inviata. Inoltre, le trap SNMP segnalano solo errori, ma non inviano notifiche di ripristino, lasciando quindi lo stato attuale del monitoraggio poco chiaro.

Infine, in caso di guasto di un servizio critico a monte in una rete di grandi dimensioni, migliaia di switch possono inviare trap contemporaneamente. Il sovraccarico di messaggi potrebbe mandare in tilt il trap receiver, rendendo il monitoraggio indisponibile proprio quando è più necessario.

La Console Eventi

Con la Event Console Checkmk offre un sistema integrato per evitare il sovraccarico del trap receiver. Ad esempio, la Console Eventi elabora i messaggi generati da un evento utilizzando il demone eventi (mkeventd) anziché il nucleo di monitoraggio. Lo scopo della Console Eventi è quello di filtrare solo i messaggi rilevanti da un grande flusso di messaggi.

A questo scopo, la Console Eventi può, tra l'altro, ricevere direttamente i messaggi via syslog o trap SNMP e classificarli in base a regole definite dall'utente. Il motore adotta l'approccio per cui la prima regola applicabile genera un evento dal messaggio. Inoltre, è in grado di correlare, riassumere, contare, annotare, riscrivere i messaggi e tenere conto delle loro relazioni temporali.

Nota: Checkmk elabora le regole come catene di regole, vale a dire che unisce diversi parametri di più regole nello stesso set di regole. Nella Console Eventi, solo la prima regola applicabile decide se un messaggio diventa un evento o se viene scartato.

Oltre al rischio di sovraccarico del ricevitore, il monitoraggio basato sugli eventi con le trap SNMP richiede un notevole sforzo di configurazione. Se l’indirizzo IP del ricevitore cambia, l’amministratore deve aggiornare la configurazione su tutti i dispositivi. Ancora più complicato è quando un aggiornamento del firmware modifica gli OID delle trap: in questo caso, l’amministratore deve riscrivere tutte le regole, a patto di accorgersi della modifica.

Un altro svantaggio del monitoraggio basato su trap è la scarsa disponibilità di strumenti per il test. Pochissimi dispositivi sono in grado di inviare trap generiche o simulare messaggi di errore reali, rendendo difficile prevedere se una trap importante funzionerà correttamente e se il messaggio verrà effettivamente inviato al verificarsi di un evento.

Un classico intramontabile

Tutto sommato, si può dire che SNMP, protocollo nato negli anni ’80, si sia affermato come standard de facto per il monitoraggio delle reti. Pur mostrando i suoi limiti col tempo, SNMP rimane un pilastro fondamentale per il controllo dei componenti di rete. Nonostante alcune carenze, soprattutto con l’aumento del numero di dispositivi, permette di monitorare rapidamente l’infrastruttura IT.

Tuttavia, gli esempi mostrati evidenziano quanto sia importante gestire ogni dispositivo integrato nell’ambiente di monitoraggio in modo specifico. L’uso di controlli SNMP generici rischia infatti di generare rapidamente dati e valori errati nella propria istanza di monitoraggio, con il pericolo di trarre conclusioni sbagliate sullo stato della rete.

Per evitare questo, è necessario utilizzare controlli progettati su misura e contare sulla competenza degli sviluppatori. A seconda della soluzione di monitoraggio adottata, questa operazione potrebbe richiedere un intervento manuale da parte dell’amministratore. Checkmk, invece, fornisce oltre 1.000 plug-in di controllo SNMP in grado di rilevare automaticamente i servizi rilevanti, permettendo così di configurare rapidamente un monitoraggio SNMP efficace.

Inoltre, Checkmk mette a disposizione strumenti dedicati ad amministratori e utenti per affrontare e risolvere alcuni problemi derivanti da implementazioni SNMP imperfette. Nel prossimo articolo scoprirai tutto sul “God Mode” e su come può supportarti nella risoluzione dei problemi SNMP.