Potresti voler utilizzare il monitoraggio SNMP su dispositivi come stampanti, switch di rete, router o UPS, che di solito sono abilitati per SNMP e sui quali sarebbe poco pratico tentare di configurare sistemi operativi completi e agent Zabbix.

Per poter recuperare i dati forniti dagli agent SNMP su questi dispositivi, il server Zabbix deve essere configurato inizialmente con il supporto SNMP specificando il flag --with-net-snmp. Si consiglia inoltre di installare i file MIB per garantire che i valori degli item vengano visualizzati nel formato corretto. Senza i file MIB, possono verificarsi problemi di formattazione, ad esempio la visualizzazione dei valori in HEX invece che in UTF-8 o viceversa.

I controlli SNMP vengono eseguiti solo tramite il protocollo UDP.

I daemon di server Zabbix e proxy registrano righe simili alla seguente se ricevono una risposta SNMP non corretta:

SNMP response from host "gateway" does not contain all of the requested variable bindings

Anche se non coprono tutti i casi problematici, sono utili per identificare i singoli dispositivi SNMP per i quali le richieste combinate dovrebbero essere disabilitate.

Il server/proxy Zabbix ritenterà fino a 5 volte per gli item SNMP walk e get. Il meccanismo di retry non si applica ai fallimenti di risoluzione DNS.

Per i controlli SNMP legacy (singolo numero OID o stringa), il server/proxy Zabbix ritenterà almeno una volta dopo un tentativo di query non riuscito: tramite il meccanismo di retry della libreria SNMP oppure tramite il meccanismo interno di elaborazione combinata.

Se si monitorano dispositivi SNMPv3, assicurarsi che msgAuthoritativeEngineID (noto anche come snmpEngineID o "Engine ID") non sia mai condiviso da due dispositivi. Secondo RFC 2571 (sezione 3.1.1.1), deve essere univoco per ciascun dispositivo.

RFC3414 richiede che i dispositivi SNMPv3 mantengano persistenti i propri engineBoots. Alcuni dispositivi non lo fanno, il che comporta che i loro messaggi SNMP vengano scartati come obsoleti dopo un riavvio. In tale situazione, la cache SNMP deve essere cancellata manualmente su un server/proxy (utilizzando -R snmp_cache_reload) oppure il server/proxy deve essere riavviato.

Configurazione del monitoraggio SNMP

Per iniziare a monitorare un dispositivo tramite SNMP, è necessario eseguire i seguenti passaggi:

Passo 1

Individua la stringa SNMP (o l'OID) dell'item che vuoi monitorare.

Per ottenere un elenco di stringhe SNMP, usa il comando snmpwalk (parte del software net-snmp, che dovresti aver installato come parte dell'installazione di Zabbix) oppure uno strumento equivalente:

snmpwalk -v 2c -c public <host IP> .

Poiché 2c qui indica la versione SNMP, puoi anche sostituirlo con 1, per indicare la versione SNMP 1 sul dispositivo.

Questo dovrebbe restituire un elenco di stringhe SNMP e del loro ultimo valore. Se non accade, è possibile che la "community" SNMP sia diversa dal valore standard public; in tal caso dovrai scoprirla.

Puoi quindi scorrere l'elenco finché non trovi la stringa che vuoi monitorare, ad esempio: se volessi monitorare i byte in ingresso sul tuo switch sulla porta 3, useresti la stringa IF-MIB::ifHCInOctets.3 da questa riga:

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

Ora puoi usare il comando snmpget per trovare l'OID numerico di IF-MIB::ifHCInOctets.3:

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

Nota che l'ultimo numero nella stringa è il numero della porta che vuoi monitorare. Vedi anche: Dynamic indexes.

Questo dovrebbe restituire qualcosa di simile a quanto segue:

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

Anche in questo caso, l'ultimo numero nell'OID è il numero della porta.

Alcuni degli OID SNMP più utilizzati vengono tradotti automaticamente in una rappresentazione numerica da Zabbix.

Nell'ultimo esempio sopra, il tipo di valore è "Counter64", che internamente corrisponde al tipo ASN_COUNTER64. L'elenco completo dei tipi supportati è ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR e ASN_OBJECT_ID. Questi tipi corrispondono approssimativamente a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" nell'output di snmpget, ma possono anche essere mostrati come "STRING", "Hex-STRING", "OID" e altri, a seconda della presenza di un display hint.

Passo 2

Crea un host corrispondente a un dispositivo.

Aggiungi un'interfaccia SNMP per l'host:

Inserisci l'indirizzo IP/nome DNS e il numero di porta.
Seleziona la versione SNMP dal menu a discesa.
Aggiungi le credenziali dell'interfaccia in base alla versione SNMP selezionata:
- SNMPv1, v2 richiedono solo la community (di solito 'public').
- SNMPv3 richiede opzioni più specifiche; vedi SNMPv3.
Specifica il valore massimo di ripetizione (predefinito: 10) per le richieste bulk SNMP native (GetBulkRequest-PDU); solo per gli item discovery[] e walk[] in SNMPv2 e v3. Tieni presente che impostare questo valore troppo alto può causare il timeout del controllo dell'agent SNMP.
Seleziona la casella Use combined requests per consentire l'elaborazione combinata delle richieste SNMP (non correlata alle richieste bulk SNMP native "walk" e "get").

Puoi usare uno dei template SNMP forniti, che aggiungerà automaticamente un insieme di item. Prima di usare un template, verifica che sia compatibile con l'host.

Fai clic su Add per salvare l'host.

SNMPv3

I seguenti parametri sono richiesti per SNMPv3:

Context name - Inserisci il nome del contesto per identificare l'item nella subnet SNMP.
I macro utente vengono risolti in questo campo.
Security name - Inserisci il nome di sicurezza.
I macro utente vengono risolti in questo campo.
Security level - Seleziona il livello di sicurezza:
- noAuthNoPriv - non vengono utilizzati né protocolli di autenticazione né di privacy;
- AuthNoPriv - viene utilizzato il protocollo di autenticazione, non quello di privacy;
- AuthPriv - vengono utilizzati sia il protocollo di autenticazione sia quello di privacy.
Authentication protocol - Seleziona il protocollo di autenticazione: MD5, SHA1; con net-snmp 5.8 e versioni successive SHA224, SHA256, SHA384 o SHA512.
Authentication passphrase - Inserisci la passphrase di autenticazione.
I macro utente vengono risolti in questo campo.
Privacy protocol - Seleziona il protocollo di privacy: DES, AES128, AES192, AES256, AES192C (Cisco) o AES256C (Cisco).
Vedi le note sul supporto del protocollo di privacy.
Privacy passphrase - Inserisci la passphrase di privacy.
I macro utente vengono risolti in questo campo.

In caso di credenziali SNMPv3 errate (security name, authentication protocol/passphrase, privacy protocol):

Zabbix riceve un errore ERROR da net-snmp, tranne nel caso di Privacy passphrase errata, in cui Zabbix riceve un errore TIMEOUT da net-snmp.
La disponibilità dell'interfaccia SNMP passerà al rosso (non disponibile).

Le modifiche a Authentication protocol, Authentication passphrase, Privacy protocol o Privacy passphrase, effettuate senza modificare il Security name, vengono normalmente applicate automaticamente quando la corrispondente interfaccia SNMPv3 viene aggiornata in Zabbix. Nei casi in cui venga modificato anche il Security name, tutti i parametri verranno aggiornati immediatamente.

Puoi usare uno dei template SNMP forniti, che aggiungerà automaticamente un insieme di item. Prima di usare un template, verifica che sia compatibile con l'host.

Fai clic su Add per salvare l'host.

Supporto del protocollo di privacy

A seconda del sistema operativo e della configurazione di net-snmp, alcuni protocolli di privacy potrebbero non essere disponibili:

Su alcuni sistemi operativi più recenti (ad esempio, RHEL9) il supporto per DES è stato rimosso dal pacchetto net-snmp.
I protocolli di crittografia AES192 e più forti non sono supportati nativamente sui sistemi operativi più vecchi di RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.

Per verificare se la libreria net-snmp supporta AES192+, usa una delle seguenti opzioni:

net-snmp-config:

net-snmp-config --configure-options

Se l'output contiene --enable-blumenthal-aes, AES192+ è supportato.

Nota che net-snmp-config fa parte del pacchetto di sviluppo per SNMP (libsnmp-dev per Debian/Ubuntu, net-snmp-devel per CentOS/RHEL/OL/SUSE) e potrebbe non essere installato per impostazione predefinita.

snmpget:

snmpget -v 3 -x AES-256

Se l'output contiene Invalid privacy protocol specified after -3x flag: AES-256, AES192+ non è supportato. Se l'output contiene No hostname specified., AES192+ non è supportato.

Se la tua libreria net-snmp non supporta i protocolli AES192 e superiori, ricompila net-snmp con l'opzione --enable-blumenthal-aes, quindi ricompila il server Zabbix specificando l'opzione --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.

Passaggio 3

Creare un item per il monitoraggio.

Ora torna in Zabbix e fai clic su Items per l'host SNMP creato in precedenza. A seconda che tu abbia utilizzato o meno un template durante la creazione dell'host, visualizzerai un elenco di item SNMP associati all'host oppure un elenco vuoto. Supponiamo che tu voglia creare personalmente l'item utilizzando le informazioni appena raccolte con snmpwalk e snmpget; fai quindi clic su Create item.

Compila i parametri obbligatori nel modulo del nuovo item:

Parametro	Descrizione
Name	Inserisci il nome dell'item.
Type	Seleziona qui SNMP agent.
Key	Inserisci una chiave significativa.
Host interface	Assicurati di selezionare l'interfaccia SNMP, ad esempio quella dello switch/router.
SNMP OID	Utilizza uno dei formati supportati per inserire i valori OID: walk[OID1,OID2,...] - recupera un sottoalbero di valori. Ad esempio: `walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3]`. Questa opzione utilizza richieste bulk SNMP native (GetBulkRequest-PDU) in modo asincrono. Le impostazioni di timeout per questo item possono essere configurate nel modulo configurazione dell'item. Valuta la possibilità di impostare un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi se quelli precedenti scadono o hanno esito negativo (ad esempio, un timeout di 3 secondi può comportare un'attesa di 15 secondi). Puoi utilizzare questo item come item master, con item dipendenti che estraggono i dati dall'item master tramite la pre-elaborazione. È possibile specificare più OID in una singola operazione snmp walk, ad esempio `walk[OID1,OID2,...]`, per elaborare in modo asincrono un OID alla volta. Se la richiesta bulk non restituisce risultati, viene effettuato un tentativo di recuperare un singolo record senza una richiesta bulk. I nomi MIB sono supportati come parametri; pertanto `walk[1.3.6.1.2.1.2.2.1.2]` e `walk[ifDescr]` restituiranno lo stesso output. Se vengono specificati più OID/MIB, ad esempio `walk[ifDescr,ifType,ifPhysAddress]`, l'output sarà un elenco concatenato. Le richieste GetBulk vengono utilizzate con le interfacce SNMPv2 e v3, mentre per le interfacce SNMPv1 viene utilizzato GetNext; il numero massimo di ripetizioni per le richieste bulk viene configurato a livello di interfaccia. Il parametro del numero massimo di ripetizioni influisce sulle richieste bulk determinando il numero massimo di OID restituiti in una singola risposta bulk. Un valore più alto produce risposte bulk più grandi, riducendo il numero di trasmissioni necessarie. Tuttavia, non tutti i dispositivi potrebbero supportare valori molto elevati, causando potenziali problemi. Questo item restituisce l'output dell'utility snmpwalk con i parametri -Oe -Ot -On. Puoi utilizzare questo item come item master in SNMP discovery. get[OID] - recupera un singolo valore in modo asincrono. Ad esempio: `get[1.3.6.1.2.1.31.1.1.1.6.3]` Le impostazioni di timeout per questo item possono essere configurate nel modulo configurazione dell'item. Valuta la possibilità di impostare un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi se quelli precedenti scadono o hanno esito negativo (ad esempio, un timeout di 3 secondi può comportare un'attesa di 15 secondi). OID - (legacy) inserisci un singolo OID testuale o numerico per recuperare un singolo valore in modo sincrono, eventualmente combinato con altri valori. Ad esempio: `1.3.6.1.2.1.31.1.1.1.6.3`. Per questa opzione, il timeout del controllo dell'item sarà uguale al valore impostato nel file di configurazione del server. È consigliato utilizzare gli item `walk[OID]` e `get[OID]` per ottenere prestazioni migliori. Tutti gli item `walk[OID]` e `get[OID]` vengono eseguiti in modo asincrono: non è necessario ricevere la risposta a una richiesta prima di avviare altri controlli. Anche la risoluzione DNS è asincrona. La concorrenza massima dei controlli asincroni è 1000 (definita da MaxConcurrentChecksPerPoller). Il numero di poller SNMP asincroni è definito dal parametro StartSNMPPollers. Nota che, per le statistiche sul traffico di rete restituite da uno qualsiasi dei metodi, è necessario aggiungere un passaggio Change per second nella scheda Preprocessing; in caso contrario, otterrai il valore cumulativo dal dispositivo SNMP invece della variazione più recente.

Tutti i campi di input obbligatori sono contrassegnati da un asterisco rosso.

Ora salva l'item e vai a Monitoring > Latest data per visualizzare i dati SNMP.

Esempio 1

Esempio generale:

Parametro	Descrizione
OID	1.2.3.45.6.7.8.0 (oppure .1.2.3.45.6.7.8.0)
Key	<Stringa univoca da utilizzare come riferimento per i trigger> Per esempio, "my_param".

Si noti che l'OID può essere fornito sia in forma numerica che come stringa. Tuttavia, in alcuni casi, l'OID in formato stringa deve essere convertito nella rappresentazione numerica. L'utilità snmpget può essere utilizzata a questo scopo:

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Esempio 2

Monitoraggio dell'uptime:

Parameter	Descrizione
OID	MIB::sysUpTime.0
Key	router.uptime
Value type	Float
Units	uptime
Preprocessing step: Custom multiplier	0.01

Richieste bulk SNMP native

L'item walk[OID1,OID2,...] consente di utilizzare la funzionalità SNMP nativa per le richieste bulk (GetBulkRequest-PDUs), disponibile nelle versioni SNMP 2/3.

Una richiesta GetBulk in SNMP esegue più richieste GetNext e restituisce il risultato in un'unica risposta. Può essere utilizzata per normali item SNMP così come per il discovery SNMP, per ridurre al minimo i round trip di rete.

L'item SNMP walk[OID1,OID2,...] può essere utilizzato come item master che raccoglie i dati in un'unica richiesta, con item dipendenti che analizzano la risposta secondo necessità utilizzando il preprocessing.

Si noti che l'utilizzo di richieste bulk SNMP native non è correlato all'opzione di combinare richieste SNMP, che è il modo proprio di Zabbix di combinare più richieste SNMP (vedere la sezione successiva).

Per gli item bulk SNMP verranno effettuati fino a cinque tentativi per evitare errori nel caso in cui uno dei pacchetti venga perso. Il timeout per gli item SNMP con get e walk (impostato nel modulo di configurazione dell'item) è impostato per un'intera sessione. Il timeout viene applicato indipendentemente dal fatto che i dati vengano recuperati completamente; se i dati vengono ricevuti solo parzialmente (ad esempio, i dati vengono raccolti correttamente solo per uno tra più OID), allora l'item diventa non supportato con il messaggio "Only partial data received". Se viene raggiunto il timeout, verrà effettuato un nuovo tentativo, il timeout verrà reimpostato e l'ultima richiesta verrà inviata nuovamente, consentendo di continuare la sessione dall'ultima richiesta se un singolo pacchetto è andato perso o è arrivato troppo tardi. Si consiglia di impostare un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi se i precedenti scadono o falliscono (ad esempio, un timeout di 3 secondi può comportare un tempo di attesa di 15 secondi).

Funzionamento interno dell'elaborazione combinata

Il server e il proxy Zabbix possono interrogare i dispositivi SNMP per più valori in una singola richiesta. Questo riguarda diversi tipi di item SNMP:

item SNMP normali
item SNMP con indici dinamici
regole di discovery di basso livello SNMP

Tutti gli item SNMP su una singola interfaccia con parametri identici vengono pianificati per essere interrogati contemporaneamente. I primi due tipi di item vengono acquisiti dai poller in batch di massimo 128 item, mentre le regole di discovery di basso livello vengono elaborate singolarmente, come in precedenza.

A un livello inferiore, per interrogare i valori vengono eseguiti due tipi di operazioni: ottenere più oggetti specificati e attraversare un albero OID.

Per l'operazione di "ottenimento" viene utilizzato un GetRequest-PDU con al massimo 128 associazioni di variabili. Per l'operazione di "attraversamento", viene utilizzato un GetNextRequest-PDU per SNMPv1 e un GetBulkRequest con il campo "max-repetitions" impostato a un massimo di 128 per SNMPv2 e SNMPv3.

Pertanto, i vantaggi dell'elaborazione combinata per ciascun tipo di item SNMP sono i seguenti:

gli item SNMP normali beneficiano dei miglioramenti dell'operazione di "ottenimento";
gli item SNMP con indici dinamici beneficiano dei miglioramenti sia dell'operazione di "ottenimento" sia di quella di "attraversamento": l'operazione di "ottenimento" viene utilizzata per la verifica dell'indice, mentre l'operazione di "attraversamento" viene utilizzata per creare la cache;
le regole di discovery di basso livello SNMP beneficiano dei miglioramenti dell'operazione di "attraversamento".

Tuttavia, esiste un problema tecnico: non tutti i dispositivi sono in grado di restituire 128 valori per richiesta. Alcuni restituiscono sempre una risposta corretta, mentre altri rispondono con un errore "tooBig(1)" oppure non rispondono affatto quando la risposta potenziale supera un determinato limite.

Per trovare il numero ottimale di oggetti da interrogare per un determinato dispositivo, Zabbix utilizza la strategia seguente. Inizia con cautela interrogando 1 valore per richiesta. Se l'operazione ha esito positivo, interroga 2 valori per richiesta. Se anche questa operazione ha esito positivo, interroga 3 valori per richiesta e continua in modo analogo moltiplicando per 1,5 il numero di oggetti interrogati, ottenendo la seguente sequenza di dimensioni delle richieste: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Tuttavia, quando un dispositivo rifiuta di fornire una risposta corretta, ad esempio per 42 variabili, Zabbix esegue due operazioni.

Innanzitutto, per il batch di item corrente dimezza il numero di oggetti in una singola richiesta e interroga 21 variabili. Se il dispositivo è attivo, la richiesta dovrebbe funzionare nella stragrande maggioranza dei casi, perché è noto che 28 variabili funzionano e 21 sono significativamente inferiori. Tuttavia, se anche questa operazione non riesce, Zabbix torna a interrogare i valori uno alla volta. Se anche a questo punto l'operazione non riesce, il dispositivo non sta sicuramente rispondendo e la dimensione della richiesta non è il problema.

La seconda operazione eseguita da Zabbix per i batch di item successivi consiste nell'iniziare con l'ultimo numero di variabili riuscito, 28 nel nostro esempio, e continuare ad aumentare la dimensione delle richieste di 1 fino a raggiungere il limite. Ad esempio, supponendo che la dimensione massima della risposta sia di 32 variabili, le richieste successive avranno dimensioni 29, 30, 31, 32 e 33. L'ultima richiesta non riuscirà e Zabbix non emetterà mai più una richiesta di dimensione 33. Da quel momento in poi, Zabbix interrogherà al massimo 32 variabili per questo dispositivo.

Se le richieste di grandi dimensioni non riescono con questo numero di variabili, ciò può significare una di due cose. Non è possibile conoscere i criteri esatti utilizzati da un dispositivo per limitare la dimensione della risposta, ma cerchiamo di approssimarli utilizzando il numero di variabili. La prima possibilità è che questo numero di variabili sia vicino al limite effettivo della dimensione della risposta del dispositivo nel caso generale: a volte la risposta è inferiore al limite, altre volte è superiore. La seconda possibilità è che un pacchetto UDP in una delle due direzioni sia semplicemente andato perso. Per questi motivi, se Zabbix riceve una richiesta non riuscita, riduce il numero massimo di variabili da provare per rientrare maggiormente nell'intervallo gestibile dal dispositivo, ma solo fino a due volte.

Nell'esempio precedente, se una richiesta con 32 variabili non riesce, Zabbix riduce il conteggio a 31. Se anche questa richiesta non riesce, Zabbix riduce il conteggio a 30. Tuttavia, Zabbix non ridurrà il conteggio al di sotto di 30, perché presumerà che gli ulteriori errori siano dovuti alla perdita di pacchetti UDP, anziché al limite del dispositivo.

Se, tuttavia, un dispositivo non è in grado di gestire correttamente le richieste combinate per altri motivi e l'euristica descritta sopra non funziona, per ogni interfaccia è disponibile l'impostazione "Use combined requests", che consente di disabilitare le richieste combinate per quel dispositivo.

Se le richieste combinate causano risposte parziali o malformate che producono calcoli errati al secondo (delta), ad esempio picchi apparenti nei contatori delle interfacce, disabilitare Use combined requests per l'interfaccia interessata per forzare richieste separate per ogni item; ciò spesso previene i picchi falsi. In alternativa, valutare l'utilizzo di item asincroni get[] o walk[], che vengono eseguiti in modo asincrono e non sono soggetti al batching Use combined requests per interfaccia: possono essere utilizzati al posto dei controlli OID sincroni legacy per evitare problemi correlati alle richieste combinate. Cercare nei log del server/proxy voci simili a quella mostrata nella sezione Panoramica per identificare i dispositivi interessati.

Inoltre, se l'interfaccia diventa frequentemente non disponibile, potrebbe essere necessario aumentare il parametro UnavailableDelay nei file di configurazione del server Zabbix o del proxy Zabbix per ridurre la frequenza delle richieste. Gli item potrebbero diventare non supportati se durante la discovery o l'attraversamento degli OID vengono ricevuti dati parziali.

Quali sono i prossimi passi?

1 Indici dinamici

Docs

3 agent SNMP

Panoramica