Monitoraggio tramite SNMP

Router, switch, firewall, stampanti, appliance, UPS, sensori hardware e molti altri dispositivi non consentono l'installazione di un agente Checkmk. Tuttavia, dispongono già di un'interfaccia di monitoraggio integrata fornita dal produttore: un agente SNMP. È possibile accedere a questo agente tramite il Simple Network Management Protocol (SNMP). Checkmk utilizza SNMP per monitorare tali dispositivi. Il vantaggio per te è che configurare il monitoraggio è molto semplice.

Esistono anche agenti SNMP per Windows e Linux, ma non è consigliabile utilizzarli al posto dell’agente Checkmk. SNMP non è molto performante, quindi utilizzarlo per il monitoraggio significa generalmente che il server Checkmk richiede più CPU e memoria per host rispetto a quando si lavora con il proprio agente. Inoltre, i dati forniti tramite SNMP sono incompleti. In alcuni casi, tuttavia, il monitoraggio tramite SNMP in aggiunta all’agente Checkmk può essere utile. Consulta il capitolo su SNMP e l’agente Checkmk per ulteriori informazioni su questo tema.

Tuttavia, se non esiste un plug-in dell'agente Checkmk per il monitoraggio di un particolare componente hardware o software (ad es. un controller RAID), ma il componente dispone di un'interfaccia SNMP, puoi ovviamente raccogliere ulteriori dati di monitoraggio tramite SNMP. In tal caso, assicurati che gli intervalli di query siano sufficientemente lunghi.

Monitorare i dispositivi SNMP con Checkmk è molto semplice. Se vuoi semplicemente iniziare rapidamente con SNMP, probabilmente dovrai leggere la breve sezione su SNMP nella Guida per principianti. Questo articolo, invece, approfondisce molto di più l'argomento e ti mostra tutti i dettagli e gli scenari specifici del monitoraggio SNMP con Checkmk.

Il protocollo SNMP è disponibile in diverse versioni. Questi protocolli sono tutti incompatibili tra loro, quindi il sistema di monitoraggio e il dispositivo monitorato devono sempre utilizzare la stessa versione del protocollo. Checkmk supporta le versioni v1, v2c e v3. In pratica, si stima che il 99% delle installazioni utilizzi la versione v2c. Ecco una panoramica di tutte le versioni rilevanti di SNMP:

Checkmk utilizza richieste attive per il monitoraggio SNMP – un metodo pull. Checkmk invia un pacchetto UDP (porta 161) contenente una richiesta SNMP al dispositivo, richiedendo la fornitura di dati specifici. Il dispositivo risponde quindi con un pacchetto UDP contenente la risposta (o un messaggio di errore).

SNMP ha un secondo processo: le SNMP trap. Si tratta di messaggi push spontanei inviati dai dispositivi a indirizzi configurati tramite UDP (porta 162) in modalità push. Le SNMP trap presentano molti svantaggi rispetto alle richieste attive, motivo per cui non sono molto importanti per il monitoraggio. Alcuni degli svantaggi sono:

Tuttavia, se vuoi o hai bisogno di lavorare con i trap, la Console degli Eventi offre una soluzione. Questa può ricevere i trap e generare eventi da essi.

Il primo passo è preparare il dispositivo. Ogni dispositivo SNMP ha una propria maschera di configurazione da qualche parte nella sua configurazione. Effettua le seguenti impostazioni in questa maschera di configurazione:

La community è una sorta di password, tranne per l'eccezione che non esiste un nome utente per SNMP. Esiste una convenzione secondo cui la community è public. Questo è l'impostazione predefinita per molti dispositivi — e anche per Checkmk. Ovviamente puoi obiettare che ciò non è sicuro e che dovresti specificare un'altra community. Questo ha sicuramente senso, ma devi sapere che SNMP trasmette la community in chiaro (con l'eccezione della versione 3 di SNMP). Chiunque possa intercettare i pacchetti può quindi identificare molto facilmente la community. D'altra parte, l'accesso è limitato alla sola lettura e la maggior parte delle informazioni che si possono recuperare tramite SNMP non è molto critica.

Inoltre, l’uso di comunità diverse per ogni dispositivo è molto complicato da handle. Dopotutto, queste non devono essere gestite solo nei dispositivi, ma anche nel sistema di monitoraggio. Ecco perché in pratica gli utenti di solito usano la stessa comunità ovunque — o almeno ovunque all’interno di una regione, un reparto, un data center, ecc.

Se vuoi aumentare la sicurezza anche senza SNMP versione 3, ha senso estendere il concetto di rete in modo da collocare il traffico con i servizi di gestione, e quindi anche SNMP, in una VLAN di gestione separata e proteggere quell'accesso con il firewall.

Aggiungi i dispositivi monitorati come host in Checkmk nel modo consueto. Se hai scelto la struttura delle cartelle in modo che una sola cartella contenga i dispositivi SNMP, puoi effettuare le altre impostazioni direttamente in quella cartella. Questo rende più facile aggiungere host aggiuntivi in un secondo momento ed evita anche errori.

Ora, nelle proprietà dell'host (o della cartella), nella box "Monitoring agents" imposta "Checkmk agent / API integrations" su "No API integrations, no Checkmk agent".

Nella stessa box, attiva anche "SNMP" e come protocollo SNMP seleziona "SNMPv2 or v3". La selezione della versione 1 del protocollo è una soluzione di ripiego solo per dispositivi molto vecchi. Dovresti usarla solo se sai che la v2 non è davvero supportata, o quando l'implementazione per il dispositivo è difettosa (in pratica, solo in casi isolati). Soprattutto, la versione 1 di SNMP è molto lenta perché non supporta gli accessi massivi. Questa differenza è molto significativa.

La terza e ultima impostazione si chiama SNMP credentials. Anche qui è necessario scegliere la versione del protocollo, poiché v2c e v3 differiscono in questo caso. Parleremo della versione 3 più avanti. Se non hai requisiti di sicurezza molto elevati, v2c andrà benissimo — oppure puoi collocare la comunicazione SNMP in una VLAN di gestione e renderla così sicura. SNMPv2c richiede l'inserimento della community come discusso sopra.

Esiste un modo alternativo per configurare le credenziali SNMP, se non riesci a farle passare facilmente attraverso la tua struttura di cartelle: il set di regole "Setup > Agents > SNMP rules > SNMP credentials of monitored hosts". Questo ti permetterà di assegnare le credenziali in base a tag host, etichette e proprietà simili. Il principio è che una community impostata direttamente sull'host o sulla cartella ha sempre la precedenza sulle regole.

Una volta terminate le impostazioni, puoi fare una breve deviazione alla pagina di diagnostica. Per farlo, salva con il pulsante della barra delle azioni "Save & go to connection test".

Ecco un esempio della diagnostica per uno switch. Vengono provate contemporaneamente diverse versioni del protocollo SNMP, ovvero:

Un dispositivo normale e moderno dovrebbe rispondere a tutte e quattro le varianti con gli stessi dati, anche se questo potrebbe essere limitato a seconda della configurazione. Il risultato sarà simile a questo:

Qui vengono descritte le quattro informazioni fornite:

In realtà sembra che ogni errore immaginabile che si possa teoricamente commettere nell'implementazione di SNMP sia già stato commesso da qualche produttore in qualche momento. E così ci sono dispositivi con cui SNMP funziona abbastanza bene, ma alcune parti del protocollo non funzionano o sono state implementate in modo errato.

Se i problemi si verificano con le edizioni commerciali, una delle ragioni potrebbe essere che l'implementazione SNMP in linea, più performante e attivata di default, fa maggiore affidamento sulla conformità agli standard rispetto all'snmpget. Se i dispositivi non rispondono affatto o non in modo affidabile, a volte può essere utile disattivare l'SNMP in linea per i dispositivi interessati e attivare così l'snmpget, leggermente più robusto ma significativamente più lento.

Per i test sulla riga di comando, il comando cmk ha per alcune opzioni l'opzione aggiuntiva --snmp-backend, che accetta come parametri inline (uso di SNMP in linea), classic (uso di snmpget) o stored-walk (uso di uno SNMP walk memorizzato). Se il test sulla riga di comando ha avuto esito positivo, puoi usare il set di regole Hosts not using inline SNMP per specificare gli host che non dovrebbero usare SNMP in linea in modo permanente.

Hai incluso un dispositivo SNMP nel monitoraggio, ma Checkmk riconosce solo i servizi SNMP Info e SNMP Uptime e le interfacce. Ciò può essere dovuto a diverse cause:

Se il ping funziona, ma nessuna delle versioni del protocollo SNMP funziona, le cause possibili possono essere diverse:

Di default SNMP non è crittografato e quindi l'autenticazione tramite una community trasmessa in chiaro sulla rete è molto debole. Questo livello può comunque essere sufficiente per una rete locale e isolata, poiché in questo caso il monitoraggio si limita alle operazioni di sola lettura.

Se desideri comunque un livello di sicurezza più elevato, avrai bisogno della versione 3 di SNMP. Questa offre la possibilità di crittografia e autenticazione vera e propria. Per questo, tuttavia, è necessaria anche una configurazione adeguata.

SNMPv3 riconosce vari livelli di sicurezza:

L'impostazione richiesta in Checkmk va effettuata nello stesso posto in cui hai definito la community — ovvero nelle proprietà dell'host o nella regola SNMP credentials of monitored hosts. Lì, invece di SNMP Community, seleziona uno dei tre livelli di v3 e configura i valori necessari:

SNMPv3 introduce il concetto di contesti. Un dispositivo SNMP può mostrare informazioni diverse in un unico punto dell'albero SNMP, a seconda dell'ID del contesto specificato nella query.

Se hai un dispositivo che funziona con tali contesti, avrai bisogno di due impostazioni in Checkmk:

Fortunatamente ci sono pochissime situazioni in cui devi lavorare con i contesti, perché purtroppo il monitoraggio non è in grado di riconoscerli automaticamente. È sempre necessaria una configurazione manuale dei contesti.

Le prestazioni sono sempre importanti, specialmente in ambienti con molti host, e il monitoraggio con SNMP consuma più CPU e memoria rispetto agli agenti Checkmk.

Mentre la Comunità Checkmk effettua le richieste SNMP in modo classico tramite i comandi snmpget o snmpbulkwalk, le edizioni commerciali dispongono di un motore SNMP integrato che esegue le richieste SNMP in modo molto efficiente senza generare processi aggiuntivi. In questo modo, il carico della CPU per l'elaborazione SNMP si dimezza approssimativamente. I tempi di polling più brevi riducono anche il numero di processi Checkmk necessari contemporaneamente e, di conseguenza, l'utilizzo della memoria.

Se le tue risorse raggiungono i loro limiti, o se ci vogliono più di 60 secondi per interrogare un singolo dispositivo, puoi ridurre l'intervallo con cui Checkmk interroga gli host. Con il set di regole "Normal check interval for service checks", che applichi specificamente ai servizi Checkmk degli host, puoi estendere l'intervallo generale di un minuto a, ad esempio, 2 o 5 minuti.

Soprattutto per i controlli SNMP, c'è anche il set di regole "Fetch intervals for SNMP sections". Questo ti permette di ridurre l'intervallo per i singoli plug-in di controllo. È importante sapere che non puoi mai impostare un intervallo più breve di quello previsto per il monitoraggio generale dal servizio "Check_MK".

Nel complesso, tuttavia, ti consigliamo di impostare il monitoraggio in modo da mantenere l'intervallo standard di un minuto e di aumentarlo solo in casi eccezionali per singoli host o check.

Per impostazione predefinita, Checkmk si aspetta una risposta in meno di un secondo per una richiesta SNMP. Inoltre, effettua un totale di tre tentativi prima di rinunciare. Per i dispositivi che rispondono molto lentamente o che sono raggiungibili solo tramite una rete molto lenta, potrebbe essere necessario modificare questi parametri. Puoi farlo tramite il set di regole "Timing settings for SNMP access":

Tieni presente che queste impostazioni si applicano a una singola richiesta SNMP. Il processo completo di monitoraggio di un host consiste in molte richieste separate. Il timeout totale è quindi un multiplo delle impostazioni specificate qui.

Per impostazione predefinita, SNMP trasmette 10 risposte in un unico pacchetto per ogni richiesta di GetBulk. Prova il set di regole "Bulk walk: Number of OIDs per bulk" per vedere se un valore più alto offre performance migliori. Tuttavia, questo sarà vero solo quando vengono trasferite tabelle di grandi dimensioni all'host, ad esempio se si tratta di uno switch con molte porte.

SNMP riempie sempre i pacchetti fino al numero specificato, inclusi eventuali record successivi a quelli effettivamente richiesti. E se solo alcuni di questi record sono realmente necessari, i dati in eccesso vengono trasferiti inutilmente e l'overhead aumenta.

D'altra parte, nella pratica può capitare occasionalmente che i dispositivi con il valore predefinito di 10 OID per blocco possano avere problemi. In tal caso può essere utile ridurre il numero.

Checkmk funziona normalmente acquisendo sempre le informazioni su tutte le porte dello switch, anche se non tutte sono effettivamente monitorate. Questo è comunque un bene, poiché di solito è più veloce perché le singole query non possono essere eseguite con le efficienti richieste massive. Inoltre, dal nostro punto di vista, è sempre consigliabile effettuare il monitoraggio di tutte le porte per individuare porte difettose o cavi con alti tassi di errore. Se le porte non sono affidabili UP, puoi anche contrassegnare lo stato del collegamento DOWN come OK.

Tuttavia, ci sono casi isolati in cui gli switch hanno moltissime porte e, per qualche motivo, rispondono molto lentamente o elaborano lo SNMP in modo molto inefficiente, tanto che non è più possibile effettuare il monitoraggio con il recupero completo di tutte le informazioni sulle porte.

Per questi casi, c'è il set di regole "Bulk walk: Limit SNMP OID Ranges". Questo ti permette di limitare staticamente l'elenco dei dati interrogati (ad es. le porte). Nel valore della regola, per ogni particolare plug-in di controllo specifichi quali indici della rispettiva tabella devono essere recuperati.

Il tipo di check usuale per le porte dello switch si chiama SNMP interface check with 64 bit counters (using v2c). L'esempio seguente mostra un'impostazione in cui vengono recuperate tramite SNMP solo le prime due porte:

Nota: questo filtro è quindi attivo prima della scoperta del servizio e del monitoraggio. A seconda dell'impostazione "Network interface and switch port discovery", ciò non significa automaticamente che queste due porte saranno effettivamente monitorate.

Il motore SNMP di Checkmk ha una funzione molto utile: puoi far sì che un dispositivo monitorato scriva in un file un'istantanea completa di tutti i suoi dati SNMP, un SNMP walk. Puoi usare questo file in seguito per simulare il monitoraggio del dispositivo su un altro server Checkmk, anche se quest'altro server non ha una connessione di rete effettiva con il dispositivo.

Utilizziamo questa funzione molto intensamente, ad esempio quando il nostro team di assistenza sviluppa nuovi plug-in di controllo per i nostri clienti. I nostri sviluppatori non hanno quindi bisogno di accedere ai tuoi dispositivi, ma solo di uno SNMP walk.

Puoi creare un SNMP walk direttamente dalla GUI. La funzione si trova nel menu azione del servizio "Check_MK" degli host e anche nel menu azione degli host (voce "Download SNMP walk"):

La creazione del walk richiede pochi secondi nel caso migliore, ma non è raro che ci vogliano alcuni minuti. Una volta completata la creazione, puoi effettuare lo scaricamento del file creato tramite la riga Result.

In alternativa, puoi anche creare walk dalla riga di comando. Accedi all'istanza da cui viene effettuato il monitoraggio del dispositivo. La creazione del walk si effettua semplicemente con il comando cmk --snmpwalk e l'host specificato (che deve essere configurato nel monitoraggio):

Usa anche il switch -v per visualizzare un output più dettagliato sullo stato di avanzamento:

Il file verrà salvato nella directory var/check_mk/snmpwalks, dove avrà semplicemente il nome dell'host. È un file di testo. Se sei curioso, puoi effettuare la visualizzazione, ad esempio con less; chiudi il programma con il tasto Q:

Il comando cmk --snmpwalk ha altre opzioni utili:

Se vuoi usare questo walk su un sito Checkmk diverso (o sullo stesso) per una simulazione, salva il file del walk con il nome host su questo sito sotto var/check_mk/snmpwalks. Assicurati che l'utente dell’istanza sia il proprietario del file e che i permessi siano impostati su 0600 (solo il proprietario può leggere e scrivere).

Ora crea una regola nel set di regole Simulating SNMP by using a stored SNMP walk che acceda agli host interessati.

D'ora in poi, per il monitoraggio dell'host verrà utilizzato solo il file salvato. Ora non c'è più alcun accesso di rete all'host, tranne il ping per il controllo dell'host ed eventuali active checks configurati. Puoi semplicemente reindirizzarli al server Checkmk assegnando l'indirizzo IP 127.0.0.1 agli host.