Documentation
Table of Contents
2 Agent SNMP
Vista general
És possible que vulgueu emprar el monitoratge SNMP a dispositius com ara impressores, commutadors de xarxa, encaminadors o SAIs que normalment siguin habilitats per a SNMP i on seria poc pràctic mirar de configurar sistemes operatius complets i agents de Zabbix.
Per poder recuperar les dades proporcionades pels agents SNMP en aquests dispositius, el servidor Zabbix ha d'ésser inicialment configurat amb suport SNMP especificant la bandera --with-net-snmp.
Les comprovacions d'SNMP es fan només sobre el protocol UDP.
El servidor Zabbix i els dimonis proxy registren línies similars a les següents si reben una resposta SNMP incorrecta:
Si bé no cobreixen tots els casos problemàtics, són útils per identificar dispositius SNMP individuals per als quals s'han de desactivar les peticions massives.
El servidor/proxy de Zabbix sempre tornarà a provar-ho (com a mínim un cop) després d'un intent de consulta fallit: ja sigui a través del reintent de la biblioteca SNMP o a través del mecanisme intern de processament massiu.
Si monitoreu dispositius SNMPv3, assegureu-vos que msgAuthoritativeEngineID (també conegut com snmpEngineID o "ID de motor") no sigui mai compartit per dos dispositius. Segons l'RFC2571 (secció 3.1.1.1) ha d'ésser únic per a cada dispositiu.
L'RFC3414 requereix que els dispositius SNMPv3 mantinguin els seus motorBoots. Alguns dispositius no ho fan, la qual cosa fa que els seus missatges SNMP es descartin com a obsolets després de reiniciar-se. En aquesta situació, la memòria cau SNMP s'ha d'esborrar manualment del servidor/proxy (mitjançant -R snmp_cache_reload) o el servidor/proxy s'ha de reiniciar.
configuració del monitoratge SNMP
Per engegar el monitoratge d'un dispositiu via SNMP, s'han de seguir les passes següents:
Passa 1
Descobriu la cadena SNMP (o OID) de l'element que voleu monitorar.
Per obtindre una llista de cadenes SNMP, empreu l'ordre snmpwalk (part del programari net-snmp que hauríeu d'haver instal·lat com a part de la instal·lació de Zabbix), o una eina equivalent:
Com que "2c" és la versió SNMP, també podeu substituir-la per "1", per indicar la versió 1 d'SNMP al dispositiu.
Això us hauria de donar un llistat de cadenes SNMP i el seu darrer valor. Si no és així, és possible que la "comunitat" SNMP sigui diferent de la "public" estàndard, i en aquest cas haureu d'esbrinar quina és.
Tot seguit, podeu repassar la llista fins que trobeu la cadena que voleu controlar; per exemple, si volguéssiu controlar els octets que arriben al port 3 del vostre commutador, emprareu la cadena IF-MIB::ifHCInOctets.3 d'aquesta línia:
Ara podeu emprar l'ordre snmpget per esbrinar l'OID numèric per a 'IF-MIB::ifHCInOctets.3':
Tingueu en compte que el darrer nombre de la cadena és el nombre de port que voleu monitorar. Veieu també: Índexs dinàmics.
Això us hauria de donar alguna cosa com la següent:
De nou, el darrer nombre de l'OID és el nombre de port.
Alguns dels OID SNMP més emprats són traduïts automàticament a una representació numèrica de Zabbix.
A l'exemple anterior, el tipus de valor és "Counter64", que internament correspon al tipus ASN_COUNTER64. La llista sencera de tipus admesos és ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_GAUGE, ASN_ADDRESS. , ASN_OCTET_STR i ASN_OBJECT_ID. Aquests tipus corresponen aproximadament a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" a la sortida snmpget, però també es pot mostrar com a "STRING", "Hex-STRING", "OID" i altres, depenent de la presència d'una pista de visualització.
Passa 2
Crear un equip que correspongui al dispositiu.
Afegiu una interfície SNMP per a l'equip:
- Introduïu l'adreça IP/nom DNS i el nombre de port
- Trieu la versió SNMP al menú desplegable
- Afegiu credencials de la interfície en funció de la versió SNMP seleccionada:
- SNMPv1, v2 només requereixen la comunitat (normalment 'public')
- SNMPv3 requereix opcions més específiques (veieu més avall)
- Especifiqueu el valor màxim de repetició (per defecte: 10) per a peticions massives SNMP nadiues (#native-snmp-bulk-requests) (GetBulkRequest-PDUs); només per als elements
discovery[]iwalk[]a SNMPv2 i v3 - Deixeu la casella de selecció Empra consultes massives marcada per permetre l'ús combinat de processament de peticions SNMP (no relacionat amb les peticions massives d'SNMP natives)
| Paràmetre SNMPv3 | Descripció |
|---|---|
| Nom del context | Introduïu el nom del context per identificar l'element a la subxarxa SNMP. El Nom del context és compatible amb els elements SNMPv3 des de Zabbix 2.2. Les macros d'usuari es resolen en aquest camp. |
| Nom de seguretat | Introduïu el nom de seguretat. Les macros d'usuari es resolen en aquest camp. |
| Nivell de seguretat | Trieu el nivell de seguretat: noAuthNoPriv - no s'empren protocols d'autenticació ni de privadesa AuthNoPriv - s'empra el protocol d'autenticació, no s'empra el protocol de privadesa AuthPriv - S'empren tant protocols d'autenticació com de privadesa |
| Protocol d'autenticació | Trieu el protocol d'autenticació - MD5, SHA1, SHA224, SHA256, SHA384 o SHA512. |
| Frase de pas d'autenticació | Introduïu la frase de pas d'autenticació. Les macros d'usuari s'han resolt en aquest camp. |
| Protocol de privadesa | Trieu el protocol de privadesa - DES, AES128, AES192, AES256, AES192C (Cisco) o AES256C (Cisco). |
| Frase de pas de privadesa | Introduïu la frase de pas de privadesa. Les macros d'usuari es resolen en aquest camp. |
En cas de credencials SNMPv3 incorrectes (nom de seguretat, autenticació protocol/frase de pas, protocol de privadesa):
- Zabbix rep un ERROR de net-snmp, tret d'una Frase de pas de privadesa incorrecta, en aquest cas Zabbix rep un error TIMEOUT de net-snmp;
- La disponibilitat de la interfície SNMP canvia a vermell (no disponible).
Canvis en el Protocol d'autenticació, Frase de pas d'autenticació, Protocol de privadesa o Frase de pas de privadesa, fet sense canviar el Nom de la seguretat, només tindrà efecte després la memòria cau d'un servidor/proxy s'esborra manualment (emprant -R snmp_cache_reload) o el servidor/proxy es reinicia. En els casos en què també hi ha el Nom de seguretat canviat, tots els paràmetres s'actualitzaran immediatament.
Podeu emprar una de les plantilles SNMP proporcionades, que afegirà automàticament un conjunt d'elements. No obstant això, es possible que la plantilla no sigui compatible amb l'equip.
Feu clic a Afegir per desar l'equip.
Passa 3
Crear un element per monitorar-lo.
Per tant, ara torneu a Zabbix i feu clic a Elements per a l'equip SNMP que heu creat anteriorment. Depenent de si heu emprat una plantilla o no en crear el vostre equip, tindreu una llista d'elements SNMP associats al vostre equip o només una llista buida. Treballarem en el supòsit que creareu l'element vosaltres mateixos emprant la informació que acabeu de recopilar amb snmpwalk i snmpget, així que feu clic a Crear element.
Ompliu els paràmetres demanats al nou formulari d'element:
| Paràmetre | Descripció |
|---|---|
| Nom | Introduïu el nom de l'element. |
| Tipus | Trieu agent SNMP aquí. |
| Clau | Introduïu la clau com a alguna cosa significativa. |
| Interfície de l'equip | Assegureu-vos de seleccionar la interfície SNMP, p. del vostre commutador/encaminador. |
| SNMP OID | Aquest camp admet dues opcions: 1) Introduïu un únic OID textual o numèric, per exemple: 1.3.6.1.2.1.31.1.1.1.6.3 (en aquest cas, assegureu-vos que per afegir un pas Canvi per segon a la pestanya Preprocessament; en cas contrari, obtindreu valors acumulatius del dispositiu SNMP en lloc de l'últim canvi). 2) Empreu el walk[OID1, Element OID2,...], que fa ús de peticions massives SNMP nadiues (GetBulkRequest-PDU). Podeu emprar-lo com a element principal, amb elements dependents que extreuen dades del mestre mitjançant el preprocessament. Per exemple, walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].Aquest element retorna la sortida de la utilitat snmpwalk amb els paràmetres -Oe -Ot -On. Els noms MIB són compatibles com a paràmetres; per tant, walk[1.3.6.1.2.1.2.2.1.2] i walk[ifDescr] retornaran la mateixa sortida.Si s'especifiquen diversos OID/MIB, és a dir, walk[ifDescr,ifType,ifPhysAddress] , aleshores la sortida és una llista concatenada.Aquest element empra sol·licituds GetBulk amb interfícies SNMPv2 i v3 i GetNext per a interfícies SNMPv1; les repeticions màximes per a peticions massives es configuren a nivell d'interfície. Podeu emprar aquest element com a element principal a SNMP discovery. |
Tots els camps d'entrada obligatoris són marcats amb un asterisc vermell.
Ara deseu l'element i aneu a Monitoratge → Dades més recents per a les vostres dades SNMP.
Exemple 1
Exemple general:
| Paràmetre | Descripció |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (or .1.2.3.45.6.7.8.0) |
| Key | <Cadena única per emprar com a referència per als triggers Per exemple, "el meu_param". |
Tingueu en compte que l'OID es pot donar en forma numèrica o com a cadena. Tanmateix, en alguns casos, la cadena OID s'ha de convertir a representació numèrica. La utilitat snmpget es pot emprar per a aquest propòsit:
Exemple 2
Monitoratge de la disponibilitat:
| Paràmetre | Descripció |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | Float |
| Units | uptime |
| Passa de pretractament: multiplicador personalitzat | 0.01 |
Peticions massives SNMP nadiues
L'element walk[OID1,OID2,...] permet emprar la funcionalitat SNMP nativa per a peticions massives (GetBulkRequest-PDU), disponible a les versions SNMP 2/3.
Una petició GetBulk a SNMP executa diverses peticions GetNext i retorna el resultat en una única resposta. Això es pot emprar per a elements SNMP habituals, així com per a la descoberta d'SNMP per minimitzar els viatges d'anada i tornada a la xarxa.
L'element SNMP walk[OID1,OID2,...] es pot emprar com a element principal que recull dades en una petició amb elements dependents que analitzen la resposta segons sigui necessari mitjançant el preprocessament.
Tingueu en compte que l'ús de peticions massives SNMP nadiues no és relacionat amb l'opció de combinar peticions SNMP, que és la manera pròpia de Zabbix de combinar diverses peticions SNMP (veieu la secció següent).
Procés intern de processament massiu
El servidor Zabbix i el proxy consulten dispositius SNMP per a diversos valors en una sola petició. Això afecta diversos tipus d'elements SNMP:
- Elements SNMP habituals
- Elements SNMP amb índexs dinàmics
- SNMP regles de descoberta de baix nivell
Tots els elements SNMP d'una única interfície amb paràmetres idèntics són programats per ésser consultats a la vegada. Els enquestadors prenen els dos primers tipus d'elements en lots de com a màxim 128 articles, mentre que les regles de descoberta de baix nivell es processen individualment, com abans.
Al nivell inferior, hi ha dos tipus d'operacions fetes per consultar valors: obtindre diversos objectes especificats i executar per un arbre OID.
Per "obtindre", s'empra una GetRequest-PDU amb un màxim de 128 enllaços variables. Per a "executar", s'empra una GetNextRequest-PDU per a SNMPv1 i GetBulkRequest amb un camp "max-repetitions" com a màxim de 128 per a SNMPv2 i SNMPv3.
Així, els avantatges del processament massiu per a cada tipus d'element SNMP es descriuen a continuació:
- Els elements SNMP habituals es beneficien d'"obtindre" millores;
- Els elements SNMP amb índexs dinàmics es beneficien tant de les millores de "obtindre" com d'"executar": "obtindre" s'empra per a la verificació de l'índex i "executar" per crear la memòria cau;
- Les regles de descoberta de baix nivell SNMP es beneficien de les millores "a peu".
Tanmateix, hi ha un problema tècnic que no tots els dispositius són capaços de retornar 128 valors per pteició. Alguns sempre retornen una resposta adequada, però d'altres responen amb un error "tooBig(1)" o no responen gens quan la resposta potencial supera un cert límit.
Per trobar un nombre òptim d'objectes per consultar per a un dispositiu determinat, Zabbix empra l'estratègia següent: comença amb cura consultant 1 valor en una petició. Si això té èxit, consulta 2 valors en una petició. Si torna a tindre èxit, consulta 3 valors en una petició i continua de manera similar multiplicant el nombre d'objectes consultats per 1,5, donant lloc a la següent seqüència de mides de petició: 1, 2, 3, 4, 6, 9, 13, 19 , 28, 42, 63, 94, 128.
Tanmateix, una vegada que un dispositiu es nega a donar una resposta adequada (per exemple, per a 42 variables), Zabbix fa dues coses.
En primer lloc, per al lot d'articles actual redueix a la meitat el nombre d'objectes en una sola petició i consulta 21 variables. Si el dispositiu és viu, aleshores la consulta hauria de funcionar en la gran majoria dels casos, perquè sabia que funcionaven 28 variables i 21 és significativament menor que això. Tanmateix, si això encara falla, Zabbix torna a consultar els valors un per un. Si encara falla en aquest moment, el dispositiu definitivament no respon i la mida de la petició no és un problema.
La segona cosa que fa Zabbix per als lots d'articles posteriors és que comença amb el darrer nombre de variables exitosos (28 en el nostre exemple) i continua incrementant les mides de petició en 1 fins que arriba al límit. Per exemple, suposant que la mida de resposta més gran és de 32 variables, les peticions posteriors seran de mida 29, 30, 31, 32 i 33. La darrera petició fallarà i Zabbix no tornarà a emetre cap petició de mida 33. A partir d'aquest moment, Zabbix consultarà com a màxim 32 variables per a aquest dispositiu.
Si les consultes grans fallen amb aquest nombre de variables, pot voler dir una de dues coses. Els criteris exactes que empra un dispositiu per limitar la mida de la resposta no es poden conèixer, però intentem aproximar-ho mitjançant el nombre de variables. Per tant, la primera possibilitat és que aquest nombre de variables sigui al voltant del límit de mida de resposta real del dispositiu en el cas general: de vegades la resposta és inferior al límit, de vegades és superior. La segona possibilitat és que un paquet UDP en qualsevol direcció simplement es perdi. Per aquests motius, si Zabbix rep una consulta fallida, redueix el nombre màxim de variables per intentar aprofundir en el rang còmode del dispositiu, però (a partir de la 2.2.8) només fins a dos cops.
A l'exemple anterior, si una consulta amb 32 variables falla, Zabbix reduirà el recompte a 31. Si això també falla, Zabbix reduirà el recompte a 30. Tanmateix, Zabbix no reduirà el recompte per sota de 30, perquè suposarà que la majoria d'errors es deuen a la pèrdua de paquets UDP i no pas al límit del dispositiu.
Tanmateix, si un dispositiu no pot gestionar correctament les peticions massives per altres motius i l'heurística descrita anteriorment no funciona, des de Zabbix 2.4 hi ha una configuració "Empra peticions massives" per a cada interfície que permet desactivar les peticions massives per a aquest dispositiu.