Monitoraggio con SNMP: storie dall'inferno

Coloro che monitorano il proprio ambiente di rete con SNMP beneficiano del fatto che molti produttori supportano il Simple Network Management Protocol sui propri dispositivi. Poiché il protocollo è diventato lo standard de facto per il monitoraggio della rete dalla sua introduzione oltre 30 anni fa, quasi tutti i produttori hanno integrato un agente SNMP nei loro dispositivi. Purtroppo, però, alcuni non gestiscono l'implementazione SNMP sui propri componenti come richiesto dallo standard.

Poiché molti utenti di Checkmk monitorano i loro ambienti di rete con SNMP, sappiamo per esperienza diretta che le cattive implementazioni SNMP non sono purtroppo rare tra i produttori. In questo articolo vogliamo presentare alcuni esempi tipici di implementazioni SNMP difettose, tratti dalla nostra esperienza.

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. Per il monitoraggio dell'ambiente di rete, questo pone diversi problemi, in quanto è più difficile ottenere i dati richiesti.

Spesso è possibile ottenere le informazioni di monitoraggio necessarie con Checkmk attraverso diverse MIB standard, come Host-Resources e UCD. Tuttavia, questo è problematico, ad esempio, se entrambe le MIB forniscono valori diversi della memoria principale. Ciò può essere dovuto al fatto che una MIB fornisce un valore errato mentre l'altra trasmette le informazioni corrette. In teoria, può anche accadere che entrambi i MIB forniscano valori errati. È possibile leggere come funzionano gli OID e le MIB nel nostro primo articolo sul monitoraggio della rete con SNMP.

Se l'agente SNMP fornisce dati contraddittori o addirittura errati, l'amministratore deve cercare, per tentativi, di scoprire quale valore è corretto o errato e rimuovere le informazioni errate dal monitoraggio. Tutto ciò sembra molto complesso. La buona notizia è che Checkmk spesso sa già quali sono i valori non corretti, quindi ignora automaticamente le informazioni errate. Ciò dipende dal 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. Poiché 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 sono 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 restituisce 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.

1⁄10 mele o pere?

Come abbiamo visto, può accadere che i dispositivi forniscano uno o più valori errati. Tuttavia, questa non è l'unica possibilità di errore. Le unità non definite o dichiarate in modo errato sono sempre un argomento di discussione sufficiente durante le pause caffè dei nostri sviluppatori. Capita quindi di tanto in tanto che il produttore del dispositivo indichi come unità di misura i gradi Celsius, ma che lo sviluppatore dell'implementazione indichi nell'OID il Fahrenheit.

Una volta c'è stata anche una soluzione molto creativa in cui, sebbene la documentazione del produttore parlasse di gradi Celsius, non c'era alcuna indicazione chiara che il valore di uscita corrispondesse effettivamente a 1⁄10 °C.

Anche una documentazione inadeguata o un'implementazione creativa da parte del produttore possono generare ulteriore confusione. L'utilizzo dell'uscita "0°C" per segnalare che un sensore è difettoso o non disponibile può ovviamente portare a malintesi nel campo della misurazione della temperatura ambiente, nel peggiore dei casi anche a gravi errori.

Questi due esempi dimostrano che per l'utente può essere ingannevole affidarsi ciecamente ai dati interrogati tramite SNMP. Ciò dimostra 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 l'implementazione del protocollo SNMP non sia immune dai tipici errori di programmazione. Pertanto, gli errori comuni che si conoscono nella programmazione del software possono essere riscontrati anche nelle implementazioni SNMP. Questo può essere ben illustrato, ad esempio, dal formato della data. Invece di utilizzare il formato ISO, spesso si usa un mix delle diverse varianti più comuni a livello locale: AAAAMMGG, AAAAMMGG o AAAA. Ad esempio, la specifica 05022020 può significare 5 febbraio 2020 o 2 maggio 2020. Se l'anno è ridotto a due cifre, il formato di data 050220 può essere interpretato come 20 febbraio 2005.

Ciò significa che l'utente o lo sviluppatore del controllo deve occuparsi anche dei dettagli in questo caso. Ad esempio, abbiamo già avuto il caso in cui un produttore ha fornito tre cifre per il giorno nel suo stack SNMP nel formato data: 001 corrisponde quindi al primo giorno di ogni mese. Certo, è possibile farlo. Ma dovreste...?

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.

Per impostazione predefinita, Checkmk esegue il polling dei dispositivi a intervalli di un minuto. Come già descritto in questo articolo, rileva automaticamente gli OID necessari per i servizi da monitorare. Grazie a questa efficiente procedura, Checkmk mantiene il carico sui dispositivi il più basso possibile. Fortunatamente, la maggior parte dei dispositivi moderni non ha problemi con un intervallo di polling di un minuto. Tuttavia, la pratica dimostra che i dispositivi più vecchi o gli stack di switch al di sopra di una certa dimensione possono raggiungere i loro limiti di prestazioni.

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 post del blog 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 capita anche che una MIB non sia retrocompatibile, come invece dovrebbe essere per impostazione predefinita. Ciò è problematico se il firmware modifica l'implementazione degli OID. A seconda del firmware installato sul dispositivo di rete, è necessario sapere sotto quale OID si trova il valore che si sta cercando.

Odissea UDP

Ma non solo i polling SNMP presentano degli svantaggi. Anche le trappole SNMP spesso non funzionano come promesso. Un'implementazione difettosa può impedire l'attivazione di una trappola automatica nonostante si sia verificato un evento.

Tuttavia, questo è un altro problema se il produttore pubblicizza il suo dispositivo come dotato di supporto SNMP, ma in realtà ha integrato solo trappole basate su eventi, e quindi non consente il polling SNMP per i dati di monitoraggio. In combinazione con gli altri svantaggi delle trappole SNMP, ciò può causare problemi nel monitoraggio della rete.

Infine, il monitoraggio con le trappole è molto più soggetto a errori rispetto al monitoraggio SNMP con richieste attive. Uno dei motivi è l'inaffidabilità delle trappole SNMP. Questi vengono inviati come pacchetti UDP che possono andare persi. A causa della mancata verifica della ricezione, la perdita del pacchetto non viene rilevata, ovvero il destinatario non sa nemmeno che è stata inviata una notifica. Anche le trappole SNMP inviano solo messaggi di errore, ma non notifiche di ripristino, quindi anche lo stato attuale del monitoraggio può rimanere poco chiaro.

Inoltre, se un importante servizio a monte si guasta in un ambiente di rete di grandi dimensioni, migliaia di switch possono inviare trappole contemporaneamente. Sotto il peso di così tanti messaggi, il ricevitore di trappole potrebbe rompersi e il monitoraggio potrebbe non essere disponibile nel momento esatto in cui l'utente ne ha più bisogno.

La console eventi

Con la Event Console Checkmk offre un sistema integrato per evitare il sovraccarico del ricevitore di trappole. 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 a un possibile overflow del ricevitore, il monitoraggio basato sugli eventi con le trap SNMP può comportare un notevole impegno di configurazione. Se l'indirizzo IP del ricevitore di trap viene modificato, l'amministratore deve riconfigurare tutti i dispositivi. È ancora più fastidioso se un aggiornamento del firmware modifica gli OID delle trappole. In questo caso l'amministratore deve riscrivere tutte le regole, sempre che si accorga della modifica. La mancanza di opzioni di test per le trappole è un altro svantaggio del monitoraggio basato sugli eventi. Purtroppo solo pochi dispositivi sono in grado di inviare trappole generiche o addirittura test di messaggi di errore reali. Questo rende difficile prevedere se una trappola importante funzionerà correttamente e se un messaggio verrà attivato quando si verifica un evento.

Vecchio ma prezioso

Tutto sommato, si può dire che SNMP è un protocollo degli anni '80 che si è affermato come standard de facto, almeno per il monitoraggio della rete. Anche se prima o poi si blocca, SNMP continuerà a essere un pilastro centrale per il monitoraggio dei componenti di rete. Nonostante alcune carenze, soprattutto in tempi di aumento del numero di dispositivi, consente un rapido monitoraggio della propria infrastruttura IT.

Tuttavia, gli esempi illustrati hanno chiarito che è necessario trattare singolarmente ogni dispositivo che si integra nel proprio ambiente di monitoraggio. Controlli SNMP generici possono altrimenti portare rapidamente a dati e valori errati nella propria istanza di monitoraggio. Questo può portare a risultati e conclusioni errate sullo stato dell'ambiente di rete monitorato.

Questa situazione può essere evitata solo con controlli scritti appositamente e con la competenza degli sviluppatori. A seconda della soluzione di monitoraggio scelta, l'amministratore potrebbe doverlo fare manualmente. Checkmk, invece, offre la possibilità di rilevare automaticamente i servizi rilevanti per il monitoraggio con l'aiuto degli oltre 1.000 plug-in di controllo SNMP forniti. In questo modo, il monitoraggio può essere impostato in breve tempo con SNMP.

Inoltre, Checkmk fornisce anche strumenti per amministratori e utenti per risolvere alcuni dei problemi causati da implementazioni SNMP scadenti. Nel prossimo post del blog scoprirai tutto sulla 'Modalità Dio' e come può aiutarti nella risoluzione dei problemi SNMP.