?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 Áú»¢¶Ä²©.
Per poder recuperar les dades proporcionades pels agents SNMP en aquests dispositius, el servidor Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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' (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.
Per engegar el monitoratge d'un dispositiu via SNMP, s'han de seguir les passes seg¨¹ents:
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 que haur¨ªeu d'haver instal¡¤lat com a part de la instal¡¤laci¨® de Áú»¢¶Ä²©), 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 Áú»¢¶Ä²©.
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¨®.
Crear un equip que correspongui al dispositiu.
Afegiu una interf¨ªcie SNMP per a l'equip:
discovery[]
i walk[]
a SNMPv2 i v3±Ê²¹°ù¨¤³¾±ð³Ù°ù±ð SNMPv3 | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨® |
---|---|
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 Áú»¢¶Ä²© 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):
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.
Crear un element per monitorar-lo.
Per tant, ara torneu a Áú»¢¶Ä²© 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:
±Ê²¹°ù¨¤³¾±ð³Ù°ù±ð | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨® |
---|---|
Nom | Introdu?u el nom de l'element. |
Tipus | Trieu agent SNMP ²¹±ç³Ü¨ª. |
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 general:
±Ê²¹°ù¨¤³¾±ð³Ù°ù±ð | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨® |
---|---|
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:
Monitoratge de la disponibilitat:
±Ê²¹°ù¨¤³¾±ð³Ù°ù±ð | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨® |
---|---|
OID | MIB::sysUpTime.0 |
Key | router.uptime |
Value type | Float |
Units | uptime |
Passa de pretractament: multiplicador personalitzat | 0.01 |
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 Áú»¢¶Ä²© de combinar diverses peticions SNMP (veieu la secci¨® seg¨¹ent).
El servidor Áú»¢¶Ä²© i el proxy consulten dispositius SNMP per a diversos valors en una sola petici¨®. Aix¨° afecta diversos tipus d'elements SNMP:
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¨®:
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, Áú»¢¶Ä²© 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), Áú»¢¶Ä²© 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, Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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 Áú»¢¶Ä²© no tornar¨¤ a emetre cap petici¨® de mida 33. A partir d'aquest moment, Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 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, Áú»¢¶Ä²© reduir¨¤ el recompte a 31. Si aix¨° tamb¨¦ falla, Áú»¢¶Ä²© reduir¨¤ el recompte a 30. Tanmateix, Áú»¢¶Ä²© 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 Áú»¢¶Ä²© 2.4 hi ha una configuraci¨® "Empra peticions massives" per a cada interf¨ªcie que permet desactivar les peticions massives per a aquest dispositiu.