Monitoraggio con SNMP: risoluzione dei problemi in God Mode

Di Alexander Wilms il 14 lug 2020

Tempo di lettura 5 minuti

Il monitoraggio della rete con SNMP non funziona sempre senza problemi. Ciò è spesso dovuto al fatto che molti produttori implementano il protocollo SNMP in modo piuttosto scadente nei loro dispositivi. Nell'ultimo post del blog abbiamo già sottolineato i problemi che questo può causare al monitoraggio. Possibili segnali di problemi possono essere: il servizio Check_MK ha lo stato CRIT, si verifica un timeout durante l'inventario o i servizi Checkmk che dovrebbero essere presenti non vengono rilevati.

In questo articolo esamineremo la risoluzione dei problemi tipici di SNMP, nella cosiddetta "modalità Dio". Tuttavia, ciò significa anche che è necessario prestare particolare attenzione: da un grande potere derivano grandi responsabilità. Se implementato in modo errato, questo non risolverà il problema, ma potrebbe addirittura portare a un arresto completo del monitoraggio o causare pericolosi bug nei dispositivi che si desidera monitorare. In questo articolo daremo per scontato che avete già una buona conoscenza di Checkmk, quindi non spiegheremo qui la funzione del comando cmk. Una spiegazione dettagliata si trova nella documentazione.

Importante: Durante il debug, limitare sempre le impostazioni e i comandi al solo dispositivo interessato. Tutte le regole e le configurazioni elencate di seguito devono essere applicate SOLO agli host interessati e con attenzione.

Il post è strutturato come segue:

Nozioni di base per il debug: il comando "cmk

Partiamo dal presupposto che il comando cmk ti sia familiare. La combinazione con il comando Unix ‘time‘ è ottima per la risoluzione dei problemi. Utilizzeremo questa combinazione per rilevare vari problemi di runtime. Ad esempio, possiamo usare il comando time cmk -Iv HOSTNAME per determinare il tempo di esecuzione totale della fase di scoperta di un host:

Allo stesso modo, è possibile utilizzare time cmk -nv HOSTNAME per verificare il tempo di esecuzione dell'interrogazione dei servizi rilevati.

È possibile ottenere informazioni ancora più dettagliate utilizzando due 'v', ad esempio cmk -Ivv HOSTNAME o cmk -nvv HOSTNAME. In questo modo è possibile, tra l'altro, visualizzare gli OID che sono stati appena interrogati e quindi, ad esempio, identificare gli intervalli di OID lenti che potrebbero causare timeout.

Il tempo di esecuzione totale misurato in questo modo per la query (-n) o la discovery (-I/II) dovrebbe essere ben al di sotto dei 60 secondi per diversi motivi. Dopo tutto, il timeout standard del servizio "Check_MK" è di 60 secondi e dovrebbe quindi essere aumentato, insieme a un intervallo di controllo adeguato per le richieste di lunga durata. Un altro effetto negativo è che una richiesta molto lunga blocca anche un processo helper per questo periodo.

Attenzione: Il comando cmk -II della CLI corrisponde alla 'Tabula rasa' della GUI. Ciò significa che il suo utilizzo non è del tutto innocuo. È quindi necessario specificare sempre l'HOSTNAME concreto con questo comando, altrimenti verrà eseguita una tabula rasa sull'intero sito! (cmk -IIvv switch1.checkmk.com e non cmk -IIvv).

Tieni inoltre presente che i comandi si riferiscono sempre e solo al sito locale responsabile di un monitoraggio distribuito. È quindi necessario eseguire il comando sul sito in cui si sta monitorando l'host.

Nozioni di base per il debug: SNMP inline contro net-snmp

Checkmk utilizza SNMP inline dalla versione 1.4. Ciò significa che per impostazione predefinita non utilizziamo più gli strumenti a riga di comando del pacchetto net-snmp, ma eseguiamo la query SNMP utilizzando un modulo Python. Questo ha il vantaggio fondamentale di non dover più avviare e arrestare un processo net-snmp separato per ogni interrogazione OID. A seconda del numero di dispositivi SNMP monitorati, l'uso di SNMP inline riduce il carico della CPU di oltre il 50%.

Attualmente, SNMP inline è l'impostazione standard nella stragrande maggioranza dei casi e funziona in modo affidabile con la maggioranza assoluta degli host monitorati. Tuttavia, sono noti singoli casi in cui è stato necessario disattivare SNMP inline per un singolo host, ma questo aspetto verrà approfondito in seguito.

Nel contesto di questo articolo, disabiliteremo l'SNMP inline per un altro motivo, ossia per scopi diagnostici, e solo temporaneamente per l'host in analisi:

Con l'SNMP inline disattivato, quando si utilizzano i comandi cmk-Ivv/IIvv/nvv, è possibile vedere il comando net-snmp corrispondente e utilizzarlo per ulteriori azioni tramite il copia e incolla.

Ad esempio, con un comando cmk-Ivv HOSTNAME si ottiene il seguente risultato

e può essere utilizzato per copiare il comando ‘snmpbulkwalk -Cr10 -v2c -t 1 -c public -m "" -M "" -Cc -OQ -OU -On -Ot 192.168.1.5 .1.3.6.1.2.1.2.2.1.1’, ad esempio, e modificarlo per ulteriori analisi, se necessario.

È possibile accedere alla regola SNMP inline tramite: WATO ➳ Host & Service Parameters ➳ Access to agents ➳ Hosts not using inline SNMP.

In Checkmk 2.0, è possibile trovare la regola richiesta cercando 'Backend' nel menu Setup . In Regole SNMP è possibile creare la regola Hosts using a specific SNMP Backend (solo Enterprise Edition). Nella regola, aggiungere l'host alla voce Host espliciti e selezionare Usa backend classico alla voce Scegli backend SNMP.

Bulk requests: è tutta una questione di dimensioni

Nel nostro primo articolo sul monitoraggio della rete con SNMP abbiamo spiegato che SNMPv2c e v3 hanno il vantaggio, rispetto alla v1, di poter interrogare non solo gli OID singolarmente tramite snmpget, ma anche interi intervalli di OID in una sola volta tramite snmpbulkget o snmpbulkwalk. In Checkmk 10 gli OID sono preimpostati come 'bulk size' per impostazione predefinita. Questo ha il vantaggio decisivo in termini di prestazioni: l'istanza di monitoraggio deve eseguire una sola query invece di dieci query individuali al dispositivo. Questo riduce normalmente il carico generato, sia sul sistema monitorato che sul server di monitoraggio stesso.

Può sempre accadere che alcuni dispositivi abbiano problemi con la dimensione predefinita del bulk di 10 e che lo stack SNMP del dispositivo si blocchi a un certo punto quando si esegue una query con una dimensione del bulk superiore, ad esempio, a 8. Di conseguenza, la query sarà incompleta e i servizi non potranno più essere scoperti o interrogati.

Tuttavia, può anche accadere che il tempo totale di esecuzione di una query SNMP sia molto lungo e che, ad esempio, l'interrogazione di uno switch di grandi dimensioni si avvicini al timeout standard di 60 secondi o addirittura lo superi. In questo caso può essere utile aumentare la dimensione del bulk in modo significativo, ad esempio a 60, ma l'aumento della dimensione del bulk, sebbene sia più efficiente, può in realtà avere l'effetto opposto e aumentare il tempo di esecuzione totale. Come si può notare, ci si muove in un campo minato. A proposito di campi minati, abbiamo già sperimentato che un core switch si blocca completamente e si riavvia quando la dimensione del bulk è troppo grande!

Importante: Non possiamo suggerire una dimensione generale del bulk che funzioni sicuramente. Come spesso accade, dipende dal dispositivo in questione. Per questo motivo è necessario "smanettare" un po'. In altre parole, bisogna giocare con i valori fino a quando il problema non si presenta più e in modo che, idealmente, la query non aumenti il tempo di esecuzione totale.

Quindi, per avvicinarsi al problema, si passa alla riga di comando, come descritto nella sezione Fondamenti di debug: il comando cmk. Prima di tutto, si deve guardare a ciò che viene trovato usando cmk -IIv HOSTNAME:

Se si verificano errori in questo caso, con una seconda 'v' si può passare con il comando cmk -IIvv a una modalità ancora più loquace e, come si può vedere nel video qui sopra, rilevare gli OID lenti o che non appaiono.

Una possibile ragione può essere la dimensione del bulk, come già detto. Quindi, se abbiamo identificato un intervallo e disabilitato SNMP inline, come spiegato nella sezione Fondamenti di debug: SNMP inline vs. net-snmp è possibile analizzare specificamente l'OID o l'intervallo di OID interessato e manipolare il bulk size (-Cr10) con valori più piccoli o più grandi fino a trovare il valore ideale. Per una dimensione di bulk di -Cr24, ad esempio, il risultato è il seguente:

Una volta elaborata una combinazione di parametri funzionante, è necessario memorizzarla nelle regole WATO. Per questo abbiamo bisogno della regola Bulk walk: Numero di OID per bulk in Parametri host e servizi ➳ Accesso agli agenti. Qui è possibile regolare la dimensione del bulk:

Anche in questo caso: se si crea questa regola, essa deve essere applicata solo agli host interessati. Non applicarla mai all'intero monitoraggio!

Dopo aver creato questa regola e attivato la configurazione, occorre verificare nuovamente con i comandi cmk corrispondenti se le modifiche apportate portano ora al risultato desiderato, ovvero se i servizi mancanti possono essere interrogati.

Il tempismo è tutto

A parte questo, capita regolarmente che un intero stack SNMP reagisca molto lentamente, oppure che reagiscano solo singole aree OID. Ad esempio, i sensori di temperatura degli SFP Cisco, che possono essere interrogati con il controllo cisco_temperature.dom, sono noti per questo problema. A volte l'interrogazione di questi OID richiede molto più di un secondo per OID (a seconda del dispositivo, anche fino a sette secondi). Per impostazione predefinita, tuttavia, Checkmk è impostato per avere un timeout per OID di un secondo con SNMP inline abilitato o anche disabilitato. Tra l'altro, un timeout di un secondo con cinque tentativi è anche l'impostazione predefinita del pacchetto net-snmp.

Il risultato è che questi OID lenti aumentano significativamente il tempo totale di interrogazione SNMP: 1(s) * 5(tentativi) * x sensori.

Ad esempio, con 120 sensori e una dimensione di massa di 10, abbiamo già un tempo di esecuzione totale di circa 60(!) secondi, senza nemmeno riuscire a scoprire i sensori di temperatura, poiché siamo incappati in un timeout. In questo esempio raggiungiamo anche il timeout predefinito del servizio Check_MK stesso, quindi ci imbattiamo in un timeout generale. Il risultato è che non possiamo più "scoprire" nulla, oppure i servizi che sono già stati scoperti diventano "stantii" (questo è un esempio molto teorico, in pratica è possibile una complessità molto maggiore).

A questo punto è possibile utilizzare i comandi snmpbulkwalk e impostare i valori di timeout con l'opzione timeout (-t). Ciò consente di creare la regola Impostazioni di temporizzazione per l'accesso SNMP con i valori appropriati in WATO ➳ Host & Service Parameters ➳ Access to Agents.

Tuttavia, è necessario tenere a mente i seguenti aspetti:

I valori si applicano per OID o per intervallo di OID nel caso di snmpbulkget.
Il problema viene moltiplicato per: x secondi di timeout * numero di OID interessati * tentativi impostati.
In che modo le impostazioni di cui sopra influiscono sul tempo di esecuzione totale?
È possibile che si raggiunga il timeout totale?
L'istanza di monitoraggio può ancora controllare ogni minuto? Nota: Check_MK/Check_MK Discovery Timeout ≤ Intervallo di controllo
Quanti helper di Checkmk devo bloccare con questa soluzione? Ogni dispositivo interessato blocca un helper durante un controllo lento.

Considerando tutti questi aspetti, a volte è forse più sensato fare a meno di questi OID o controlli lenti?

Con calma...

È possibile ottenere le impostazioni di temporizzazione richieste modificando il parametro -t del comando di esempio precedente e impostandolo a sette (-t 7) secondi:

’snmpbulkwalk -Cr10 -v2c -t 7 -c public -m "" -M "" -Cc -OQ -OU -On -Ot 192.168.1.5 .1.3.6.1.2.1.2.2.1.1’

Se in questo modo hai determinato un valore di timeout che consente di leggere in modo affidabile i sensori di temperatura SFP di cui sopra, aggiungi un secondo in più per sicurezza. Le impostazioni di temporizzazione per la regola di accesso SNMP necessarie a questo scopo possono essere configurate tramite WATO ➳ Host & Service Parameters ➳ Access to Agents.

Ancora una volta è importante: Questa regola può essere applicata solo agli host interessati e mai all'intero monitoraggio! Può accadere che le implementazioni SNMP non segnalino "NO SUCH OID" alla fine di un ramo OID, ma semplicemente non rispondano affatto. Questa è una chiara violazione del protocollo da parte del produttore e, in combinazione con i lunghi timeout, fa sì che queste interrogazioni impieghino improvvisamente secoli e portino inutilmente a timeout totali. In altre parole: Aspettiamo troppo a lungo che arrivi qualcosa e non siamo consapevoli che in realtà non arriverà nulla.

Lo stesso principio si applica al tasso di riprova. È improbabile che per nove volte non ci sia risposta, ma che alla decima richiesta venga data improvvisamente una risposta. Pertanto, si dovrebbe scegliere un numero ridotto di tentativi e limitare il numero di tentativi a due o tre, ad esempio. Meglio una fine rapida con un timeout che un timeout senza fine...

... anche più lento...

Se siamo riusciti a rendere le informazioni interrogabili con le impostazioni di cui sopra - ottimo! Diventa però problematico se ci avviciniamo o addirittura superiamo il timeout totale di 60 secondi. In questo caso dobbiamo regolare il timeout totale per i servizi interessati. Per farlo, si può utilizzare la seguente regola: WATO ➳ Host & Service Parameters ➳ Monitoring Configuration ➳ Service check timeout (Microcore).
Aumentare il timeout di controllo del servizio e limitare questa regola impostando la condizione Servizi su Check_MK$ e Check_MK Discovery$.

Timeout del servizio Check_MK Microcore1

Come già detto, è necessario impostare l'intervallo di controllo in modo appropriato, circa due minuti (timeout ≤ intervallo). Altrimenti i servizi saranno "stantii", perché potranno essere controllati solo più tardi di quanto previsto dalla configurazione. Andare in WATO ➳ Host & Service Parameters ➳ Monitoring Configuration ➳ Normal check interval for service checks.

È importante che questa regola si applichi solo al servizio Check_MK e non a Check_MK Discovery o Check_MK HW/SW Inventory. Questi ultimi hanno un intervallo di controllo standard di due o 24 ore, rispettivamente, e genererebbero un carico considerevole se venissero eseguiti con un intervallo di due minuti. Pertanto, è necessario utilizzare l'espressione Check_MK$ nella condizione Servizi.

Importante: '$' è l'espressione regolare (Regexp) per la fine di una stringa. Ciò significa che il modello di ricerca corrisponde solo a Check_MK. Questo assicura che la regola non venga applicata a Check_MK-Discovery o Check_MK HW/SW Inventory, come avverrebbe con il modello di ricerca Check_MK (senza '$' - Infix Search).

Anche in questo caso è importante: Quando si creano queste regole, esse devono essere applicate solo all'host o agli host interessati. Non applicarle mai al monitoraggio complessivo!

... oh, ora è troppo lento!

Ma se si giunge alla conclusione che si preferisce eseguire il polling dello switch più spesso di ogni due, o anche solo ogni dieci minuti, e che i sensori di temperatura lenti sembrano piuttosto inutili, si può disattivare il controllo corrispondente. A volte questa è la scelta migliore. La regola necessaria è riportata di seguito: WATO ➳ Host & Service Parameters ➳ Monitoring Configuration ➳ Disabled checks.

Sai già che questo autore non ama ripetersi, ma è necessario farlo: Quando si creano queste regole, esse devono essere applicate solo all'host o agli host in questione. Non applicarle mai al monitoraggio complessivo! Unica eccezione: Non vuoi vedere i servizi su nessuno dei tuoi dispositivi, anche se in casi eccezionali potrebbero rispondere velocemente.

A questo punto, vorremmo anche sottolineare brevemente che la disattivazione di singoli servizi tramite una regola del tipo "Servizi disabilitati" non è un'alternativa efficace per questo caso d'uso. Finché viene interrogato un solo sensore, viene eseguito l'intero controllo, anche a causa della dimensione della massa.

Disattivare SNMP inline come soluzione

Infine, in alcuni casi può essere necessario disattivare SNMP inline per alcuni host. Ad esempio, abbiamo avuto il caso di un dispositivo che riempiva in modo affidabile e stoico con un 1 il numero di sequenza SNMP che dovrebbe essere contato con ogni risposta. Questa è un'altra chiara violazione RFC e il modulo SNMP di Python rifiutava costantemente questi pacchetti. Tuttavia, gli strumenti a riga di comando del pacchetto net-snmp non hanno riscontrato alcun problema, quindi siamo stati in grado di aiutare il cliente fornendo una regola granulare per questo singolo host, come avrai già intuito. Più sostenibile, ma meno divertente, sarebbe ovviamente un biglietto per il produttore di hardware.

Conclusione

Come abbiamo visto, la "S" di SNMP sta per "semplice", ma questo vale solo se il produttore ha implementato tutte le RFC in modo corretto e pulito. In caso contrario, il sistema si complica rapidamente in modo arbitrario con numerose impostazioni, talvolta interconnesse o addirittura inaspettatamente controproducenti. E in questo articolo non abbiamo nemmeno toccato i contesti SNMPv3 e altre cose simili. Tuttavia, speriamo che questa risoluzione dei problemi ti abbia aiutato a identificare e risolvere eventuali problemi SNMP nel tuo ambiente di monitoraggio.

Nella prossima e ultima parte della nostra serie Monitoraggio della rete con SNMP vogliamo dare uno sguardo agli sviluppi futuri del monitoraggio SNMP e discutere dei possibili successori. Oppure SNMP continuerà a soddisfarci per i prossimi 30 anni?