3 agent SNMP
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, Zabbix server deve essere inizialmente configurato 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 Zabbix server 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 bindingsSebbene non coprano tutti i casi problematici, sono utili per identificare singoli dispositivi SNMP per i quali le richieste combinate dovrebbero essere disabilitate.
Zabbix server/proxy 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 (numero OID singolo o stringa), Zabbix server/proxy ritenterà almeno una volta dopo un tentativo di interrogazione 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 ogni dispositivo.
RFC3414 richiede che i dispositivi SNMPv3 mantengano persistente 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 richieste bulk SNMP native (PDU GetBulkRequest); solo per gli item
discovery[]ewalk[]in SNMPv2 e v3. Tieni presente 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 |
|---|---|
| Context name | Inserisci il nome del contesto per identificare l'item nella subnet SNMP. In questo campo vengono risolte le macro utente. |
| Security name | Inserisci il nome di sicurezza. In questo campo vengono risolte le macro utente. |
| Security level | 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 |
| 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. In questo campo vengono risolte le macro utente. |
| 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. In questo campo vengono risolte le macro utente. |
In caso di credenziali SNMPv3 errate (security name, authentication protocol/passphrase, privacy protocol):
- Zabbix riceve un ERRORE 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 aggiungeranno 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 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.
Passo 3
Creare un item per il monitoraggio.
Quindi, 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. Lavoreremo partendo dal presupposto che creerai tu stesso l'item usando le informazioni che hai appena raccolto 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 la key in modo significativo. |
| 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 di item configuration. Valuta di impostare un 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 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 le interfacce SNMPv2 e v3 e GetNext per le interfacce SNMPv1; le max repetitions 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 di item configuration. Valuta di impostare un 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 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 configuration file. È consigliato usare gli 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 inizino altri controlli. Anche la risoluzione DNS è asincrona.La concorrenza massima dei controlli asincroni è 1000 (definita da MaxConcurrentChecksPerPoller). Il numero di SNMP poller asincroni è definito dal parametro StartSNMPPollers. Nota che, per le statistiche del traffico di rete restituite da uno qualsiasi dei metodi, nel tab 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.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 dispositivi SNMP per più valori in una singola richiesta. Questo influisce su diversi tipi di item SNMP:
- item SNMP normali
- item SNMP con indici dinamici
- regole di discovery low-level 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 elaborati dai poller in batch di massimo 128 item, mentre le regole di discovery low-level vengono elaborate singolarmente, come in precedenza.
A un livello inferiore, per l'interrogazione dei valori vengono eseguiti due tipi di operazioni: ottenere più oggetti specificati ed eseguire il walk di un albero OID.
Per il "getting", viene usato un GetRequest-PDU con al massimo 128 variable binding. 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 inferiore. Tuttavia, se anche questo fallisce, Zabbix torna a interrogare i valori uno per uno. Se a questo punto fallisce ancora, allora il dispositivo non sta sicuramente rispondendo 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, ciò può significare una di due cose. Non è possibile conoscere il criterio esatto usato da un dispositivo per limitare la dimensione della risposta, ma cerchiamo di approssimarlo 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 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 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, considera 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.
Cerca voci di log di server/proxy simili a quella mostrata nella sezione Overview per aiutarti 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 il discovery o i walk OID vengono ricevuti dati parziali.