3 agent SNMP

Panoramica

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 installare 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

Sebbene non coprano tutti i casi problematici, sono utili per identificare i singoli dispositivi SNMP per i quali le richieste combinate devono essere disabilitate.

Il server/proxy Zabbix ritenterà fino a 5 volte (a partire da Zabbix 7.0.14) 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 monitornano 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, e ciò comporta che i loro messaggi SNMP vengano scartati come obsoleti dopo un riavvio. In tale situazione, la cache SNMP deve essere svuotata 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:

Passaggio 1

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

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

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

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

Questo dovrebbe fornirti un elenco di stringhe SNMP e del loro ultimo valore.
Se così non fosse, è possibile che la 'community' SNMP sia diversa dalla 'public' standard; in tal caso dovrai scoprire quale sia.

Puoi quindi scorrere l'elenco finché non trovi la stringa che vuoi monitorare, ad esempio,
se volessi monitorare i byte in ingresso al 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: Indici dinamici.

Questo dovrebbe restituire qualcosa di simile al seguente:

.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 sotto).
  • Specifica il valore massimo di ripetizione (predefinito: 10) per richieste bulk SNMP native (PDU GetBulkRequest); solo per gli item discovery[] e walk[] in SNMPv2 e v3. Nota che impostare questo valore troppo alto può causare il timeout del controllo dell'agent SNMP.
  • Seleziona la casella Usa richieste combinate per consentire l'elaborazione combinata delle richieste SNMP (non correlata alle richieste bulk SNMP native "walk" e "get").
Parametro SNMPv3 Descrizione
Nome contesto Inserisci il nome del contesto per identificare l'item nella subnet SNMP.
Le macro utente vengono risolte in questo campo.
Nome di sicurezza Inserisci il nome di sicurezza.
Le macro utente vengono risolte in questo campo.
Livello di sicurezza Seleziona il livello di sicurezza:
noAuthNoPriv - non vengono usati protocolli di autenticazione né di privacy
AuthNoPriv - viene usato il protocollo di autenticazione, non quello di privacy
AuthPriv - vengono usati sia il protocollo di autenticazione sia quello di privacy
Protocollo di autenticazione Seleziona il protocollo di autenticazione - MD5, SHA1; con net-snmp 5.8 e versioni successive SHA224, SHA256, SHA384 o SHA512.
Passphrase di autenticazione Inserisci la passphrase di autenticazione.
Le macro utente vengono risolte in questo campo.
Protocollo di privacy Seleziona il protocollo di privacy - DES, AES128, AES192, AES256, AES192C (Cisco) o AES256C (Cisco).
Vedi le note sul supporto del protocollo di privacy
Passphrase di privacy Inserisci la passphrase di privacy.
Le macro utente vengono risolte in questo campo.

In caso di credenziali SNMPv3 errate (nome di sicurezza, protocollo/passphrase di autenticazione, protocollo di privacy):

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

Le modifiche a Protocollo di autenticazione, Passphrase di autenticazione, Protocollo di privacy o Passphrase di privacy, effettuate senza modificare il Nome di sicurezza, vengono normalmente applicate automaticamente quando la corrispondente interfaccia SNMPv3 viene aggiornata in Zabbix. Nei casi in cui venga modificato anche il Nome di sicurezza, 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 dei protocolli 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:

  1. 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.

  1. 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.

Passo 3

Crea un item per il monitoraggio.

Ora torna in Zabbix e fai clic su Items per l'host SNMP che hai creato in precedenza. A seconda che tu abbia usato o meno un template durante la creazione dell'host, avrai un elenco di item SNMP associati al tuo host oppure solo un elenco vuoto. Partiremo dal presupposto che tu voglia creare l'item manualmente usando le informazioni appena raccolte con snmpwalk e snmpget, quindi fai clic su Create item.

Compila i parametri richiesti nel nuovo modulo dell'item:

Parameter Description
Name Inserisci il nome dell'item.
Type Seleziona SNMP agent qui.
Key Inserisci una key significativa.
Host interface Assicurati di selezionare l'interfaccia SNMP, ad esempio quella del tuo switch/router.
SNMP OID Usa uno dei formati supportati per inserire il valore o 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 native SNMP bulk requests (GetBulkRequest-PDUs) in modo asincrono.
Le impostazioni di timeout per questo item possono essere configurate nel modulo item configuration. Valuta di impostare un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi (da Zabbix 7.0.14) se i precedenti vanno in timeout o falliscono (ad esempio, un timeout di 3 secondi può comportare un'attesa di 15 secondi).
Puoi usare questo item come master item, con item dipendenti che estraggono i dati dal master tramite preprocessing.
È possibile specificare più OID in un singolo snmp walk, ad esempio walk[OID1,OID2,...], per elaborare in modo asincrono un OID alla volta.
Se la richiesta bulk non restituisce risultati, viene tentato il recupero di un singolo record senza richiesta bulk.
I nomi MIB sono supportati come parametri; quindi 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 usate con interfacce SNMPv2 e v3 e GetNext per interfacce SNMPv1; le ripetizioni massime per le richieste bulk sono configurate a livello di interfaccia.
Il parametro max repetitions 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, il che potrebbe causare problemi.
Questo item restituisce l'output dell'utilità snmpwalk con i parametri -Oe -Ot -On.
Puoi usare questo item come master item 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 item configuration. Valuta di impostare un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi (da Zabbix 7.0.14) se i precedenti vanno in timeout o falliscono (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.

Si consiglia di usare item walk[OID] e get[OID] per prestazioni migliori. Tutti gli item walk[OID] e get[OID] vengono eseguiti in modo asincrono: non è necessario ricevere la risposta a una richiesta prima che vengano avviati 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 del traffico di rete restituite da uno qualsiasi dei metodi, nella scheda Preprocessing deve essere aggiunto un passaggio Change per second; in caso contrario, otterrai il valore cumulativo dal dispositivo SNMP invece dell'ultima variazione.

Tutti i campi obbligatori sono contrassegnati da un asterisco rosso.

Ora salva l'item e vai su Monitoring > Latest data per i tuoi 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 SNMP bulk native

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

Una richiesta GetBulk in SNMP esegue più richieste GetNext e restituisce il risultato in un'unica risposta. Questo può essere usato sia per i normali item SNMP sia per la discovery SNMP, per ridurre al minimo i roundtrip di rete.

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

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

Per gli item SNMP bulk verranno effettuati fino a cinque retry (da Zabbix 7.0.14) per evitare un errore se uno dei pacchetti viene perso. Il timeout per gli item SNMP con get e walk (impostato nel modulo configurazione item) è definito per un'intera sessione. Il timeout viene applicato indipendentemente dal fatto che i dati siano stati recuperati completamente; se i dati vengono ricevuti solo parzialmente (ad esempio, i dati vengono raccolti con successo solo per uno dei vari OID), allora l'item diventa non supportato con il messaggio "Only partial data received". Se viene raggiunto il timeout, verrà eseguito un retry, il timeout verrà reimpostato e l'ultima richiesta verrà reinviata, consentendo di continuare la sessione dall'ultima richiesta se un singolo pacchetto viene perso o arriva troppo tardi. Valutare l'impostazione di un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 retry se i precedenti vanno in timeout o falliscono (ad esempio, un timeout di 3 secondi può comportare un'attesa di 15 secondi).

Funzionamento interno dell'elaborazione combinata

Zabbix server e proxy possono interrogare dispositivi SNMP per più valori in una singola richiesta. Questo influisce su diversi tipi di item SNMP:

Tutti gli item SNMP su una singola interfaccia con parametri identici vengono pianificati per essere interrogati nello stesso momento. I primi due tipi di item vengono gestiti dai poller in batch di massimo 128 item, mentre le regole di discovery low-level vengono elaborate singolarmente, come in precedenza.

A livello inferiore, per l'interrogazione dei valori vengono eseguiti due tipi di operazioni: ottenere più oggetti specificati e fare il walk di un albero OID.

Per il "getting", viene usato un GetRequest-PDU con al massimo 128 binding di variabile. Per il "walking", viene usato un GetNextRequest-PDU per SNMPv1 e un GetBulkRequest con campo "max-repetitions" di al massimo 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 del "getting";
  • gli item SNMP con indici dinamici beneficiano sia dei miglioramenti del "getting" sia di quelli del "walking": il "getting" viene usato per la verifica dell'indice e il "walking" per la costruzione della cache;
  • le regole di discovery low-level SNMP beneficiano dei miglioramenti del "walking".

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

Per trovare il numero ottimale di oggetti da interrogare per un determinato dispositivo, Zabbix usa la seguente strategia. Inizia con cautela interrogando 1 valore per richiesta. Se ha successo, interroga 2 valori per richiesta. Se ha successo di nuovo, interroga 3 valori per richiesta e continua in modo simile moltiplicando il numero di oggetti interrogati per 1,5, 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 azioni.

Per prima cosa, per il batch di item corrente dimezza il numero di oggetti in una singola richiesta e interroga 21 variabili. Se il dispositivo è attivo, la query dovrebbe funzionare nella grande maggioranza dei casi, perché 28 variabili erano note per funzionare e 21 è significativamente meno. Tuttavia, se anche questo fallisce, Zabbix torna a interrogare i valori uno per uno. Se a questo punto continua a fallire, allora il dispositivo non risponde sicuramente e la dimensione della richiesta non è un problema.

La seconda cosa che Zabbix fa per i batch di item successivi è iniziare con l'ultimo numero di variabili riuscito (28 nel nostro esempio) e continuare ad aumentare la dimensione delle richieste di 1 fino al raggiungimento del limite. Ad esempio, supponendo che la dimensione massima della risposta sia 32 variabili, le richieste successive avranno dimensioni 29, 30, 31, 32 e 33. L'ultima richiesta fallirà e Zabbix non invierà mai più una richiesta di dimensione 33. Da quel momento in poi, Zabbix interrogherà al massimo 32 variabili per questo dispositivo.

Se le richieste grandi falliscono con questo numero di variabili, può significare una di due cose. I criteri esatti usati da un dispositivo per limitare la dimensione della risposta non possono essere conosciuti, ma cerchiamo di approssimarli usando il numero di variabili. Quindi la prima possibilità è che questo numero di variabili sia vicino al limite reale di dimensione della risposta del dispositivo nel caso generale: a volte la risposta è inferiore al limite, a 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 query fallita, riduce il numero massimo di variabili da provare per entrare più a fondo nell'intervallo confortevole del dispositivo, ma solo fino a due volte.

Nell'esempio sopra, se una query con 32 variabili dovesse fallire, Zabbix ridurrà il conteggio a 31. Se anche questo dovesse fallire, Zabbix ridurrà il conteggio a 30. Tuttavia, Zabbix non ridurrà il conteggio sotto 30, perché presumerà che ulteriori fallimenti siano dovuti alla perdita di pacchetti UDP, e non al limite del dispositivo.

Se invece un dispositivo non riesce a gestire correttamente le richieste combinate per altri motivi e l'euristica descritta sopra non funziona, esiste un'impostazione "Use combined requests" per ciascuna interfaccia che consente di disabilitare le richieste combinate per quel dispositivo.

Se le richieste combinate causano risposte parziali o malformate che portano a calcoli per-secondo (delta) errati (ad esempio, picchi apparenti nei contatori dell'interfaccia), disabilitare Use combined requests per l'interfaccia interessata per forzare query separate per item; questo spesso previene picchi falsi. In alternativa, valutare l'uso di item asincroni get[] o walk[], che vengono eseguiti in modo asincrono e non sono soggetti al batching per-interfaccia di Use combined requests — possono essere usati al posto dei controlli OID sincroni legacy per evitare problemi legati alle richieste combinate. Cercare voci di log di server/proxy simili a quella mostrata nella sezione Overview per aiutare a identificare i dispositivi interessati.

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