?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 de ser inicialment configurat amb suport SNMP especificant l'asenyalador --with-net-snmp
.Tamb¨¦ es recomana instal¡¤lar fitxers MIB per assegurar que els valors dels elements es mostren en el format correcte. Sense els fitxers MIB, es poden donar problemes de format, com ara veure valors en HEX en lloc d'UTF-8 o viceversa.
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 ¨²²Ô¾±³¦ 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_IPADDRESS. , ASN_OCTET_STR i ASN_OBJECT_ID. Aquests tipus corresponen aproximadament a "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. 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). Fixeu-vos que: - en alguns sistemes antics, net-snmp pot no admetre AES256; - en alguns sistemes m¨¦s nous (com ara RHEL9) el suport de DES es pot descartar per al paquet net-snmp. |
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.
Segons el vostre sistema operatiu i la configuraci¨® de net-snmp, ¨¦s possible que alguns protocols de privadesa no siguin pas disponibles:
En alguns sistemes operatius m¨¦s nous (per exemple, RHEL9) el suport de DES s'elimina per al paquet net-snmp.
Els protocols de xifrat AES192 i m¨¦s robustos no s'admeten per defecte als sistemes operatius anteriors a RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.
Per comprovar si la biblioteca net-snmp admet AES192+, empreu una de les opcions seg¨¹ents:
net-snmp-config
:
net-snmp-config --configure-options
Si la sortida cont¨¦ --enable-blumenthal-aes
, suporta AES192+.
Tingueu en compte que net-snmp-config forma part del paquet de desenvolupament per a SNMP (libsnmp-dev per a Debian/Ubuntu, net-snmp-devel per a CentOS/RHEL/OL/SUSE) i ¨¦s possible que no sigui pas instal¡¤lat per defecte.
snmpget
:
snmpget -v 3 -x AES-256
Si la sortida cont¨¦ Protocol de privadesa no v¨¤lid especificat despr¨¦s de la marca -3x: AES-256
, AES192+ no ¨¦s compatible. Si la sortida cont¨¦ No s'ha especificat cap nom d'equip.
, AES192+ no ¨¦s compatible.
Si la vostra biblioteca net-snmp no admet protocols AES192 i superiors, recompileu net-snmp amb l'opci¨® --enable-blumenthal-aes
i, a continuaci¨®, recompileu el servidor Áú»¢¶Ä²© especificant l'opci¨® --with-net-snmp=/home/user /yourcustomnetsnmp/bin/net-snmp-config
.
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 triar una interf¨ªcie SNMP d'un equip vostre (com ara un commutador/encaminador). |
SNMP OID | Empreu un dels formats admesos per introduir valors OID: walk[OID1,OID2,...] - recupera un subarbre de valors. Per exemple: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3] .Aquesta opci¨® fa ¨²s de peticions massives SNMP natives (GetBulkRequest-PDU) de manera as¨ªncrona. La configuraci¨® del temps d'espera d'aquest element es pot establir al formulari configuraci¨® de l'element. Podeu emprar-lo com a element mestre, amb elements dependents que extreuen dades del mestre mitjan?ant el preprocessament. ?s possible especificar diversos OID en una sola caminada snmp, com ara walk[OID1,OID2,...] per processar de manera as¨ªncrona un OID a la vegada.Si la sol¡¤licitud massiva no retorna cap resultat, s'intenta recuperar un sol registre sense sol¡¤licitud massiva. 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.Les peticions GetBulk s'empren 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. Aquest element retorna la sortida de la utilitat snmpwalk amb els par¨¤metres -Oe -Ot -On. Podeu emprar aquest element com a element principal a [SNMP discovery] (/manual/discovery/low_level_discovery/examples/snmp_oids_walk). get[OID] - recupera un valor ¨²²Ô¾±³¦ de manera as¨ªncrona. Per exemple: get[1.3.6.1.2.1 .31.1.1.1.6.3] La configuraci¨® del temps d'espera d'aquest element es pot establir al formulari configuraci¨® de l'element. OID* * - (heretat) introdu?u un ¨²²Ô¾±³¦ OID textual o num¨¨ric per recuperar un valor ¨²²Ô¾±³¦ de forma sincr¨°nica, opcionalment combinat amb altres valors. Per exemple: 1.3.6.1.2.1.31.1.1.1.6.3 .Per a aix¨° opci¨®, el temps d'espera de comprovaci¨® de l'element ser¨¤ igual al valor establert al servidor fitxer de configuraci¨®. Es recomanat** utilitzar walk Elements [OID] i get[OID] per a un millor rendiment. Tots els elements walk[OID] i get[OID] s'executen de manera as¨ªncrona; no ¨¦s necessari rebre la resposta a una petici¨® abans que s'inici?n altres comprovacions. La resoluci¨® de DNS tamb¨¦ ¨¦s as¨ªncrona.La concurr¨¨ncia m¨¤xima de comprovacions as¨ªncrones ¨¦s 1000 (definida per MaxConcurrentChecksPerPoller). El nombre d'enquestadors SNMP as¨ªncrons es defineix pel par¨¤metre StartSNMPPollers. Tingueu en compte que per a les estad¨ªstiques de tr¨¤nsit de xarxa, retornades per qualsevol dels m¨¨todes, un Canvi per segon s'ha d'afegir a la pestanya Preprocessament; en cas contrari, obtindreu el valor acumulat del dispositiu SNMP en lloc del darrer canvi. |
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 ¨²²Ô¾±³¦a 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 ¨²²Ô¾±³¦a 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).
Es tornar¨¤ a provar per als elements massius SNMP per evitar errors si es perd un dels paquets. El temps d'espera per als elements SNMP amb get
i walk
¨¦s establert per a tota la sessi¨®. Si s'arriba al temps d'espera, es tornar¨¤ a provar un cop, el temps d'espera es restablir¨¤ i es tornar¨¤ a enviar la darrera petici¨®, permetent continuar la sessi¨® des de la darrera petici¨® si es perd un sol paquet o arriba massa tard.
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 ¨²²Ô¾±³¦a 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.
A m¨¦s, si la interf¨ªcie sovint no ¨¦s disponible, caldr¨¤ augmentar el par¨¤metre UnavailableDelay
als fitxers de configuraci¨® del Servidor Áú»¢¶Ä²© o proxy Áú»¢¶Ä²© per reduir la freq¨¹¨¨ncia de peticions. Els articles es podrien no admetre si es rep inormaci¨® parcias durant la descoberta o les passejades OID.