Documentation
Table of Contents
2 Agente SNMP
¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô general
Es posible que desee utilizar la supervisi¨®n SNMP en dispositivos como impresoras, conmutadores de red, enrutadores o UPS que normalmente est¨¢n habilitados para SNMP y en los que ser¨ªa poco pr¨¢ctico intentar configurar sistemas operativos completos y agentes Áú»¢¶Ä²©.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, el servidor Áú»¢¶Ä²© debe estar inicialmente configurado con soporte SNMP especificando el indicador --with-net-snmp.
Las comprobaciones SNMP se realizan ¨²nicamente a trav¨¦s del protocolo UDP.
Los daemons de servidor y proxy de Áú»¢¶Ä²© registran l¨ªneas similares a las siguientes si reciben una respuesta SNMP incorrecta:
La respuesta SNMP del host "gateway" no contiene todos los enlaces de variables solicitados
Si bien no cubren todos los casos problem¨¢ticos, son ¨²tiles para identificar dispositivos SNMP individuales para los cuales se deben deshabilitar las solicitudes combinadas.
El servidor/proxy de Áú»¢¶Ä²© siempre volver¨¢ a intentarlo al menos una vez despu¨¦s de un intento de consulta infructuoso: ya sea a trav¨¦s del mecanismo de reintento de la biblioteca SNMP o a trav¨¦s del mecanismo interno de procesamiento combinado.
Si monitorea dispositivos SNMPv3, aseg¨²rese de que msgAuthoritativeEngineID (tambi¨¦n conocido como snmpEngineID o "ID del motor") nunca sea compartido por dos dispositivos. Seg¨²n (secci¨®n 3.1.1.1), debe ser ¨²nica para cada dispositivo.
RFC3414 requiere que los dispositivos SNMPv3 conserven sus engineBoots. Algunos dispositivos no lo hacen, lo que hace que sus mensajes SNMP se descarten por obsoletos despu¨¦s de reiniciarse. En tal situaci¨®n, la cach¨¦ SNMP debe borrarse manualmente en un servidor/proxy (mediante el uso de -R snmp_cache_reload) o debe reiniciarse el servidor/proxy.
°ä´Ç²Ô´Ú¾±²µ³Ü°ù²¹³¦¾±¨®²Ô de la monitorizaci¨®n SNMP
Para comenzar a monitorizar un dispositivo a trav¨¦s de SNMP, se deben realizar los siguientes pasos:
Paso 1
Encuentre la cadena SNMP (u OID) de la m¨¦trica que desea monitorear.
Para obtener una lista de cadenas SNMP, use el comando snmpwalk (parte del software que deber¨ªa haber instalado como parte de la instalaci¨®n de Áú»¢¶Ä²©) o una herramienta equivalente:
Como '2c' aqu¨ª representa la versi¨®n SNMP, tambi¨¦n puede sustituirlo por '1', para indicar la versi¨®n 1 de SNMP en el dispositivo.
Esto deber¨ªa brindarle una lista de cadenas SNMP y su ¨²ltimo valor. Si no es as¨ª, es posible que la 'comunidad' SNMP sea diferente de la est¨¢ndar 'public' , en cuyo caso deber¨¢ averiguar cu¨¢l es.
Luego, puede recorrer la lista hasta encontrar la cadena que desea monitorear, por ejemplo, si desea monitorear los bytes que ingresan a su conmutador en el puerto 3, deber¨¢ usar la cadena IF-MIB::ifHCInOctets.3 de esta l¨ªnea:
Ahora puede usar el comando snmpget para averiguar el OID num¨¦rico de 'IF-MIB::ifHCInOctets.3':
Observe que el ¨²ltimo n¨²mero en la cadena es el n¨²mero de puerto que desea monitorear. Consulte tambi¨¦n: ?ndices din¨¢micos.
Esto deber¨ªa darte algo como lo siguiente:
Nuevamente, el ¨²ltimo n¨²mero en el OID es el n¨²mero de puerto.
Algunos de los OID de SNMP m¨¢s utilizados son traducidos autom¨¢ticamente a una representaci¨®n num¨¦rica por Áú»¢¶Ä²©.
En el ¨²ltimo ejemplo anterior, el tipo de valor es "Counter64", que internamente corresponde al tipo ASN_COUNTER64. La lista completa de tipos admitidos es 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 y ASN_OBJECT_ID. Estos tipos corresponden aproximadamente a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" en la salida de snmpget, pero tambi¨¦n pueden mostrarse como "STRING", "Hex-STRING", "OID" y otros, seg¨²n la presencia de una sugerencia de visualizaci¨®n.
Paso 2
Cree un equipo correspondiente a un dispositivo.
Agregue una interfaz SNMP para el equipo:
- Ingrese la direcci¨®n IP/nombre DNS y el n¨²mero de puerto
- Seleccione la versi¨®n SNMP del men¨² desplegable
- Agregue las credenciales de la interfaz seg¨²n la versi¨®n SNMP seleccionada:
- SNMPv1, v2 requiere solo la comunidad (generalmente 'p¨²blica')
- SNMPv3 requiere opciones m¨¢s espec¨ªficas (consulte a continuaci¨®n)
- Especifique el valor de repetici¨®n m¨¢ximo (predeterminado: 10) para solicitudes masivas SNMP nativas (GetBulkRequest-PDUs); solo para elementos
discovery[]ywalk[]en SNMPv2 y v3. Tenga en cuenta que si se establece este valor demasiado alto, puede provocar que se agote el tiempo de espera de verificaci¨®n del agente SNMP. - Marque la casilla de verificaci¨®n Usar solicitudes combinadas para permitir el procesamiento combinado de solicitudes SNMP (no relacionadas con las solicitudes masivas SNMP nativas "walk" y "get")
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç SNMPv3 | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô |
|---|---|
| Nombre de contexto | Ingrese el nombre de contexto para identificar el elemento en la subred SNMP. Las macros de usuario se resuelven en este campo. |
| Nombre de seguridad | Ingrese el nombre de seguridad. Las macros de usuario se resuelven en este campo. |
| Nivel de seguridad | Seleccione el nivel de seguridad: noAuthNoPriv: no se utilizan protocolos de autenticaci¨®n ni de privacidad AuthNoPriv: se utiliza el protocolo de autenticaci¨®n, pero no el protocolo de privacidad AuthPriv: se utilizan tanto el protocolo de autenticaci¨®n como el de privacidad |
| Protocolo de autenticaci¨®n | Seleccione el protocolo de autenticaci¨®n: MD5, SHA1; con net-snmp 5.8 y versiones posteriores, SHA224, SHA256, SHA384 o SHA512. |
| Frase de contrase?a de autenticaci¨®n | Ingrese la frase de contrase?a de autenticaci¨®n. Las macros de usuario se resuelven en este campo. |
| Protocolo de privacidad | Seleccione el protocolo de privacidad: DES, AES128, AES192, AES256, AES192C (Cisco) o AES256C (Cisco). Consulte las notas sobre soporte de protocolo de privacidad |
| Frase de contrase?a de privacidad | Ingrese la frase de contrase?a de privacidad. Las macros de usuario se resuelven en este campo. |
En caso de credenciales SNMPv3 incorrectas (nombre de seguridad, protocolo de autenticaci¨®n/frase de contrase?a, protocolo de privacidad):
- Áú»¢¶Ä²© recibe un ERROR de net-snmp, excepto si la Frase de contrase?a de privacidad es incorrecta, en cuyo caso Áú»¢¶Ä²© recibe un error de TIEMPO DE ESPERA de net-snmp;
- La disponibilidad de la interfaz SNMP cambiar¨¢ a rojo (no disponible).
Los cambios en el Protocolo de autenticaci¨®n, la Frase de contrase?a de autenticaci¨®n, el Protocolo de privacidad o la Frase de contrase?a de privacidad, realizados sin cambiar el Nombre de seguridad, tendr¨¢n efecto solo despu¨¦s de que se borre manualmente la memoria cach¨¦ de un servidor/proxy (mediante el uso de -R snmp_cache_reload) o se reinicie el servidor/proxy. En los casos en que tambi¨¦n se cambie el Nombre de seguridad, todos los par¨¢metros se actualizar¨¢n inmediatamente.
Puede utilizar una de las plantillas SNMP proporcionadas que agregar¨¢n autom¨¢ticamente un conjunto de m¨¦tricas. Antes de utilizar una plantilla, verifique que sea compatible con el equipo.
Haga clic en Agregar para guardar el equipo.
Compatibilidad con protocolos de privacidad
Seg¨²n el sistema operativo y la configuraci¨®n de net-snmp, es posible que algunos protocolos de privacidad no est¨¦n disponibles:
En algunos sistemas operativos m¨¢s nuevos (por ejemplo, RHEL9), se ha eliminado la compatibilidad con DES para el paquete net-snmp.
Los protocolos de cifrado AES192 y superiores no son compatibles de f¨¢brica en los sistemas operativos anteriores a RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04 y openSUSE Leap 15.5.
Para comprobar si la biblioteca net-snmp es compatible con AES192+, utilice una de las siguientes opciones:
net-snmp-config:net-snmp-config --configure-options
Si la salida contiene --enable-blumenthal-aes, se admite AES192+.
Tenga en cuenta que net-snmp-config es parte del paquete de desarrollo para SNMP (libsnmp-dev para Debian/Ubuntu, net-snmp-devel para CentOS/RHEL/OL/SUSE) y es posible que no est¨¦ instalado de forma predeterminada.
snmpget:snmpget -v 3 -x AES-256
Si la salida contiene Protocolo de privacidad no v¨¢lido especificado despu¨¦s del indicador -3x: AES-256, no se admite AES192+. Si la salida contiene No se especific¨® ning¨²n nombre de host., no se admite AES192+.
Si su biblioteca net-snmp no admite protocolos AES192 y superiores, vuelva a compilar net-snmp con la opci¨®n --enable-blumenthal-aes, luego vuelva a compilar el servidor Áú»¢¶Ä²© especificando la opci¨®n --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
Paso 3
Cree una m¨¦trica para monitorear.
Ahora, regrese a Áú»¢¶Ä²© y haga clic en ²Ñ¨¦³Ù°ù¾±³¦²¹s para el equipo SNMP que cre¨® anteriormente. Dependiendo de si utiliz¨® una plantilla o no al crear su equipo, tendr¨¢ una lista de m¨¦tricas SNMP asociados con su equipo o solo una lista vac¨ªa. Trabajaremos asumiendo que va a crear la m¨¦trica usted mismo utilizando la informaci¨®n que acaba de recopilar utilizando snmpwalk y snmpget, as¨ª que haga clic en Crear m¨¦trica.
Complete los par¨¢metros requeridos en el formulario de nueva m¨¦trica:
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô |
|---|---|
| Nombre | Ingrese el nombre de la m¨¦trica. |
| Tipo | Seleccione agente SNMP ²¹±ç³Ü¨ª. |
| Clave | Ingrese la clave de forma que tenga sentido. |
| Interfaz del equipo | Aseg¨²rese de seleccionar la interfaz SNMP, por ejemplo, de su conmutador/enrutador. |
| SNMP OID | Use uno de los formatos admitidos para ingresar los valores de OID: walk[OID1,OID2,...] - recupera un sub¨¢rbol de valores. Por ejemplo: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].Esta opci¨®n hace uso de solicitudes masivas de SNMP nativas (GetBulkRequest-PDUs) de forma asincr¨®nica. La configuraci¨®n de tiempo de espera para esta m¨¦trica se puede configurar en el formulario configuraci¨®n de m¨¦trica. Puede usarlo como la m¨¦trica maestra, con m¨¦tricas dependientes que extraen datos del maestro mediante preprocesamiento. Es posible especificar m¨²ltiples OID en un solo recorrido snmp, como walk[OID1,OID2,...] para procesar asincr¨®nicamente un OID a la vez.Si la solicitud masiva no devuelve resultados, se intenta recuperar un solo registro sin solicitud masiva. Los nombres de MIB se admiten como par¨¢metros; por lo tanto, walk[1.3.6.1.2.1.2.2.1.2] y walk[ifDescr] devolver¨¢n la misma salida.Si se especifican varios OID/MIB, es decir, walk[ifDescr,ifType,ifPhysAddress], la salida es una lista concatenada.Las solicitudes GetBulk se utilizan con interfaces SNMPv2 y v3 y GetNext para interfaces SNMPv1; Las repeticiones m¨¢ximas para solicitudes en bloque se configuran en el nivel de interfaz. Esta m¨¦trica devuelve la salida de la utilidad snmpwalk con los par¨¢metros -Oe -Ot -On. Puede utilizar esta m¨¦trica como m¨¦trica maestra en el descubrimiento de SNMP. get[OID]: recupera un valor ¨²²Ô¾±³¦´Ç de forma asincr¨®nica. Por ejemplo: get[1.3.6.1.2.1.31.1.1.1.6.3]La configuraci¨®n de tiempo de espera para esta m¨¦trica se puede configurar en el formulario configuraci¨®n de m¨¦trica. OID: (heredado) ingrese un OID num¨¦rico o textual ¨²²Ô¾±³¦´Ç para recuperar un valor ¨²²Ô¾±³¦´Ç de forma sincr¨®nica, combinado opcionalmente con otros valores. Por ejemplo: 1.3.6.1.2.1.31.1.1.1.6.3.Para esta opci¨®n, el tiempo de espera de la comprobaci¨®n de m¨¦tricas ser¨¢ igual al valor establecido en el archivo de configuraci¨®n del servidor. Se recomienda utilizar las m¨¦tricas walk[OID] y get[OID] para obtener un mejor rendimiento. Todas las m¨¦tricas walk[OID] y get[OID] se ejecutan de forma asincr¨®nica: no es necesario recibir la respuesta a una solicitud antes de que se inicien otras comprobaciones. La resoluci¨®n de DNS tambi¨¦n es asincr¨®nica.La concurrencia m¨¢xima de comprobaciones asincr¨®nicas es 1000 (definida por MaxConcurrentChecksPerPoller). La cantidad de sondeadores SNMP asincr¨®nicos se define mediante el par¨¢metro StartSNMPPollers. Tenga en cuenta que para las estad¨ªsticas de tr¨¢fico de red, devueltas por cualquiera de los m¨¦todos, se debe agregar un paso de Cambio por segundo en la pesta?a Preprocesamiento; de lo contrario, obtendr¨¢ el valor acumulado del dispositivo SNMP en lugar del ¨²ltimo cambio. |
Todos los campos de entrada obligatorios est¨¢n marcados con un asterisco rojo.
Ahora guarde la m¨¦trica y vaya a Monitoreo ¡ú Datos m¨¢s recientes para sus datos SNMP.
Ejemplo 1
Ejemplo general:
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (o .1.2.3.45.6.7.8.0) |
| Clave | <Cadena ¨²nica que se utilizar¨¢ como referencia para los iniciadores> Por ejemplo, "my_param". |
Tenga en cuenta que el OID se puede proporcionar en forma num¨¦rica o de cadena. Sin embargo, en algunos casos, la cadena OID debe convertirse a una representaci¨®n num¨¦rica. Se puede utilizar la utilidad snmpget para este prop¨®sito:
Ejemplo 2
Monitoreo del tiempo de actividad:
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô |
|---|---|
| OID | MIB::sysUpTime.0 |
| Clave | router.uptime |
| Tipo de valor | Flotante |
| Unidades | tiempo de actividad |
| Paso de preprocesamiento: Multiplicador personalizado | 0.01 |
Solicitudes masivas de SNMP nativas
La m¨¦trica walk[OID1,OID2,...] permite utilizar la funcionalidad nativa de SNMP para solicitudes masivas (PDU GetBulkRequest), disponible en las versiones 2/3 de SNMP.
Una solicitud GetBulk en SNMP ejecuta m¨²ltiples solicitudes GetNext y devuelve el resultado en una ¨²nica respuesta. Esto se puede utilizar para m¨¦tricas SNMP normales, as¨ª como para el descubrimiento de SNMP para minimizar los viajes de ida y vuelta por la red.
La m¨¦trica SNMP walk[OID1,OID2,...] se puede utilizar como la m¨¦trica maestra que recopila datos en una solicitud con m¨¦tricas dependientes que analizan la respuesta seg¨²n sea necesario mediante el preprocesamiento.
Tenga en cuenta que el uso de solicitudes masivas de SNMP nativas no est¨¢ relacionado con la opci¨®n de combinar solicitudes SNMP, que es la forma propia de Áú»¢¶Ä²© de combinar m¨²ltiples solicitudes SNMP (consulte la siguiente secci¨®n).
Se producir¨¢ un reintento para las m¨¦tricas masivas de SNMP para evitar un error si se pierde uno de los paquetes. El tiempo de espera para las m¨¦tricas SNMP con get y walk se establece para toda la sesi¨®n. Si se alcanza el tiempo de espera, se realizar¨¢ un reintento una vez, se restablecer¨¢ el tiempo de espera y se volver¨¢ a enviar la ¨²ltima solicitud, lo que permitir¨¢ continuar la sesi¨®n desde la ¨²ltima solicitud si se pierde un solo paquete o llega demasiado tarde.
Funcionamiento interno del procesamiento combinado
El servidor y el proxy Áú»¢¶Ä²© pueden consultar dispositivos SNMP para m¨²ltiples valores en una ¨²nica solicitud. Esto afecta a varios tipos de m¨¦tricas SNMP:
- ²Ñ¨¦³Ù°ù¾±³¦²¹s SNMP normales
- ²Ñ¨¦³Ù°ù¾±³¦²¹s SNMP con ¨ªndices din¨¢micos
- Reglas de descubrimiento de bajo nivel SNMP
Todos las m¨¦tricas SNMP en una ¨²nica interfaz con par¨¢metros id¨¦nticos est¨¢n programados para ser consultados al mismo tiempo. Los primeros dos tipos de m¨¦tricas son tomados por los encuestadores en lotes de 128 m¨¦tricas como m¨¢ximo, mientras que las reglas de descubrimiento de bajo nivel se procesan individualmente, como antes.
En el nivel inferior, hay dos tipos de operaciones realizadas para consultar valores: obtener m¨²ltiples objetos especificados y recorrer un ¨¢rbol OID.
Para "obtener", se utiliza una PDU GetRequest con un m¨¢ximo de 128 enlaces de variables . Para "recorrer", se utiliza una PDU GetNextRequest para SNMPv1 y una GetBulkRequest con un campo "max-repetitions" de un m¨¢ximo de 128 para SNMPv2 y SNMPv3.
Por lo tanto, los beneficios del procesamiento combinado para cada tipo de elemento SNMP se describen a continuaci¨®n:
- las m¨¦tricas SNMP regulares se benefician de las mejoras de "obtenci¨®n";
- las m¨¦tricas SNMP con ¨ªndices din¨¢micos se benefician tanto de las mejoras de "obtenci¨®n" como de "recorrer": "obtener" se utiliza para la verificaci¨®n de ¨ªndice y "recorrer" para construir la memoria cach¨¦;
- las reglas de descubrimiento de bajo nivel de SNMP se benefician de las mejoras de "recorrer".
Sin embargo, existe un problema t¨¦cnico: no todos los dispositivos son capaces de devolver 128 valores por solicitud. Algunos siempre devuelven una respuesta adecuada, pero otros responden con un error "tooBig(1)" o no responden en absoluto una vez que la respuesta potencial supera un cierto l¨ªmite.
Para encontrar una cantidad ¨®ptima de objetos para consultar para un dispositivo determinado, Áú»¢¶Ä²© utiliza la siguiente estrategia. Comienza con cautela consultando 1 valor en una solicitud. Si eso tiene ¨¦xito, consulta 2 valores en una solicitud. Si eso tiene ¨¦xito nuevamente, consulta 3 valores en una solicitud y contin¨²a de manera similar multiplicando la cantidad de objetos consultados por 1,5, lo que da como resultado la siguiente secuencia de tama?os de solicitud: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
Sin embargo, una vez que un dispositivo se niega a dar una respuesta adecuada (por ejemplo, para 42 variables), Áú»¢¶Ä²© hace dos cosas.
En primer lugar, para el lote de m¨¦tricas actual, reduce a la mitad la cantidad de objetos en una sola solicitud y consulta 21 variables. Si el dispositivo est¨¢ activo, entonces la consulta deber¨ªa funcionar en la gran mayor¨ªa de los casos, porque se sab¨ªa que 28 variables funcionaban y 21 es significativamente menos que eso. Sin embargo, si eso sigue fallando, Áú»¢¶Ä²© vuelve a consultar los valores uno por uno. Si sigue fallando en este punto, entonces el dispositivo definitivamente no responde y el tama?o de la solicitud no es un problema.
La segunda cosa que hace Áú»¢¶Ä²© para los lotes de m¨¦tricas posteriores es que comienza con la ¨²ltima cantidad exitosa de variables (28 en nuestro ejemplo) y contin¨²a incrementando los tama?os de las solicitudes en 1 hasta que se alcanza el l¨ªmite. Por ejemplo, suponiendo que el tama?o de respuesta m¨¢s grande es de 32 variables, las solicitudes subsiguientes ser¨¢n de tama?os 29, 30, 31, 32 y 33. La ¨²ltima solicitud fallar¨¢ y Áú»¢¶Ä²© nunca volver¨¢ a emitir una solicitud de tama?o 33. A partir de ese momento, Áú»¢¶Ä²© consultar¨¢ como m¨¢ximo 32 variables para este dispositivo.
Si las consultas grandes fallan con esta cantidad de variables, puede significar una de dos cosas. No se puede conocer el criterio exacto que utiliza un dispositivo para limitar el tama?o de respuesta, pero tratamos de aproximarnos a eso usando la cantidad de variables. Por lo tanto, la primera posibilidad es que esta cantidad de variables est¨¦ alrededor del l¨ªmite de tama?o de respuesta real del dispositivo en el caso general: a veces la respuesta es menor que el l¨ªmite, a veces es mayor que eso. La segunda posibilidad es que un paquete UDP en cualquier direcci¨®n simplemente se haya perdido. Por estos motivos, si Áú»¢¶Ä²© recibe una consulta fallida, reduce el n¨²mero m¨¢ximo de variables para intentar llegar m¨¢s lejos en el rango c¨®modo del dispositivo, pero solo hasta dos veces.
En el ejemplo anterior, si una consulta con 32 variables falla, Áú»¢¶Ä²© reducir¨¢ el recuento a 31. Si eso tambi¨¦n falla, Áú»¢¶Ä²© reducir¨¢ el recuento a 30. Sin embargo, Áú»¢¶Ä²© no reducir¨¢ el recuento por debajo de 30, porque asumir¨¢ que los fallos posteriores se deben a la p¨¦rdida de paquetes UDP, en lugar del l¨ªmite del dispositivo.
Sin embargo, si un dispositivo no puede manejar solicitudes combinadas correctamente por otras razones y la heur¨ªstica descrita anteriormente no funciona, hay una configuraci¨®n "Usar solicitudes combinadas" para cada interfaz que permite deshabilitar las solicitudes combinadas para ese dispositivo.