2 SNMP agent
Panoramica
Potresti voler utilizzare il monitoraggio SNMP su dispositivi come stampanti, switch di rete, router o UPS, che di solito supportano 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, come la visualizzazione dei valori in HEX invece che in UTF-8 o viceversa.
I controlli SNMP vengono eseguiti solo tramite il protocollo UDP.
I demoni server e proxy di Zabbix 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 bindingsSebbene non coprano tutti i casi problematici, sono utili per identificare 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 ritentativo non si applica agli errori di risoluzione DNS.
Per i controlli SNMP legacy (un singolo numero OID o una stringa), il server/proxy Zabbix ritenterà almeno una volta dopo un tentativo di query non riuscito: tramite il meccanismo di ritentativo della libreria SNMP oppure tramite il meccanismo interno di elaborazione combinata.
Se monitori dispositivi SNMPv3, assicurati 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 persistano il proprio engineBoots. Alcuni dispositivi non lo fanno, con il risultato che i loro messaggi SNMP vengono scartati come obsoleti dopo il 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.
Zabbix memorizza nella cache le associazioni SNMPv3 EngineID → IP e riutilizza gli EngineID memorizzati per i controlli successivi invece di inviare ogni volta una probe, riducendo il traffico di rete. Se un EngineID non può essere riutilizzato, verrà eseguito un nuovo tentativo con una probe per individuare il nuovo EngineID.
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: 3409739121Ora 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.3Nota 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: 3472126941Anche 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.
Passaggio 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 le richieste bulk SNMP native (GetBulkRequest-PDUs); solo per gli item
discovery[]ewalk[]in SNMPv2 e v3. Nota che impostare questo valore troppo alto può causare il timeout del controllo dell'agent SNMP. - Seleziona la casella di controllo 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 sulla 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 utilizzati protocolli di autenticazione né di privacy AuthNoPriv - viene utilizzato il protocollo di autenticazione, il protocollo di privacy no AuthPriv - vengono utilizzati 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 ERROR 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 utilizzare uno dei template SNMP forniti che aggiungerà automaticamente un insieme di item. Prima di utilizzare un template, verifica che sia compatibile con l'host.
Fai clic su Aggiungi 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 superiori non sono supportati out-of-the-box sui sistemi operativi precedenti a 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+, utilizzare una delle seguenti opzioni:
net-snmp-config:
net-snmp-config --configure-optionsSe l'output contiene --enable-blumenthal-aes, AES192+ è supportato.
Si noti 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-256Se 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 libreria net-snmp non supporta i protocolli AES192 e superiori, ricompilare net-snmp con l'opzione --enable-blumenthal-aes, quindi ricompilare Zabbix server specificando l'opzione --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
Passaggio 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 utilizzato o meno un template durante la creazione del tuo host, vedrai un elenco di item SNMP associati al tuo host oppure semplicemente un elenco vuoto. Lavoreremo partendo dal presupposto che creerai tu stesso l'item utilizzando le informazioni che hai appena raccolto con snmpwalk e snmpget, quindi fai clic su Create item.
Compila i parametri richiesti nel modulo del nuovo item:
| Parameter | Description |
|---|---|
| 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 del tuo switch/router. |
| SNMP OID | Usa 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 in modo asincrono le richieste bulk SNMP native (GetBulkRequest-PDUs). Le impostazioni di timeout per questo item possono essere configurate nel modulo di configurazione dell'item. Valuta l'impostazione di un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi 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 come item master, con item dipendenti che estraggono dati dal master tramite preprocessing. È 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 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, mentre GetNext con interfacce SNMPv1; il numero massimo di ripetizioni per le richieste bulk è configurato 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 item master in SNMP discovery. get[OID] - recupera in modo asincrono un valore singolo. 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 di configurazione dell'item. Valuta l'impostazione di un valore di timeout basso per evitare lunghi ritardi se il dispositivo non è raggiungibile, poiché verranno effettuati fino a 5 tentativi 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 in modo sincrono un singolo valore, facoltativamente 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. Tieni presente che per le statistiche del 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 dell'ultima variazione. |
Tutti i campi di input obbligatori sono contrassegnati da un asterisco rosso.
Ora salva l'item e vai in 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.0Esempio 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
Zabbix server e proxy possono interrogare i dispositivi SNMP per più valori in una singola richiesta. Questo riguarda diversi tipi di item SNMP:
- item SNMP regolari
- item SNMP con indici dinamici
- regole di low-level discovery 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 presi dai poller in batch di al massimo 128 item, mentre le regole di low-level discovery vengono elaborate singolarmente, come in precedenza.
A un livello inferiore, esistono due tipi di operazioni eseguite per interrogare i valori: ottenere più oggetti specificati e percorrere un albero OID.
Per l'"ottenimento", viene utilizzato un GetRequest-PDU con al massimo 128 associazioni di variabili. Per il "walking", viene utilizzato un GetNextRequest-PDU per SNMPv1 e GetBulkRequest con il campo "max-repetitions" di al massimo 128 per SNMPv2 e SNMPv3.
Pertanto, i vantaggi dell'elaborazione combinata per ciascun tipo di item SNMP sono illustrati di seguito:
- gli item SNMP regolari beneficiano dei miglioramenti nell'"ottenimento";
- gli item SNMP con indici dinamici beneficiano sia dei miglioramenti nell'"ottenimento" sia di quelli nel "walking": l'"ottenimento" viene utilizzato per la verifica dell'indice e il "walking" per costruire la cache;
- le regole SNMP di low-level discovery beneficiano dei miglioramenti nel "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 un numero ottimale di oggetti da interrogare per un determinato dispositivo, Zabbix utilizza la seguente strategia. Inizia con cautela interrogando 1 valore in una richiesta. Se l'operazione ha successo, interroga 2 valori in una richiesta. Se anche questa ha successo, interroga 3 valori in una richiesta e continua in modo analogo 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 si rifiuta di fornire una risposta corretta (ad esempio, per 42 variabili), Zabbix esegue due operazioni.
Innanzitutto, per il batch corrente di item dimezza il numero di oggetti in una singola richiesta e interroga 21 variabili. Se il dispositivo è attivo, nella stragrande maggioranza dei casi la richiesta dovrebbe funzionare, perché 28 variabili erano note per funzionare e 21 è significativamente inferiore. Tuttavia, se anche questo fallisce, Zabbix torna a interrogare i valori uno per uno. Se anche a questo punto fallisce, allora il dispositivo sicuramente non sta rispondendo e la dimensione della richiesta non è il problema.
La seconda cosa che Zabbix fa per i batch successivi di item è iniziare con l'ultimo numero di variabili che ha avuto successo (28 nel nostro esempio) e continuare ad aumentare la dimensione delle richieste di 1 finché non viene raggiunto 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 fallirà 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 richieste di grandi dimensioni falliscono con questo numero di variabili, ciò può significare una di due cose. I criteri esatti che un dispositivo utilizza per limitare la dimensione della risposta non possono essere conosciuti, ma si cerca di approssimarli usando il numero di variabili. Quindi, 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, a volte lo supera. 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 per cercare di rientrare maggiormente nell'intervallo di funzionamento sicuro del dispositivo, ma solo fino a due volte.
Nell'esempio sopra, se una richiesta con 32 variabili fallisce, Zabbix ridurrà il conteggio a 31. Se anche questa fallisce, Zabbix ridurrà il conteggio a 30. Tuttavia, Zabbix non ridurrà il conteggio al di sotto di 30, perché presumerà che ulteriori errori siano dovuti alla perdita di pacchetti UDP, piuttosto che al limite del dispositivo.
Se invece un dispositivo non è in grado di gestire correttamente le richieste combinate per altri motivi e l'euristica descritta sopra non funziona, esiste un'impostazione "Use combined requests" per ogni interfaccia che consente di disabilitare le richieste combinate per quel dispositivo.
Se le richieste combinate causano risposte parziali o malformate che producono calcoli per secondo (delta) errati (ad esempio, picchi apparenti nei contatori di interfaccia), disabilitare Use combined requests per l'interfaccia interessata per forzare richieste separate per singolo item; questo spesso evita falsi picchi.
In alternativa, considerare 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 utilizzati al posto dei controlli OID sincroni legacy per evitare problemi correlati alle richieste combinate.
Cercare nel log di server/proxy voci simili a quella mostrata nella sezione Overview per aiutare a identificare i dispositivi interessati.
Inoltre, se l'interfaccia diventa frequentemente non disponibile, potrebbe 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 le operazioni di OID walk vengono ricevuti dati parziali.