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 no sería práctico intentar configurar sistemas operativos completos y agentes de Zabbix.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, el servidor Zabbix debe ser configurado inicialmente con compatibilidad con SNMP especificando el indicador --with-net-snmp
.
Las comprobaciones SNMP se realizan únicamente a través del protocolo UDP.
El servidor Zabbix y los demonios proxy registran líneas similares a las mostradas a continuación si reciben una respuesta SNMP incorrecta:
La respuesta SNMP de la "puerta de enlace" del host 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 desactivar las solicitudes combinadas.
El servidor/proxy Zabbix siempre volverá a intentarlo al menos una vez después de un intento de consulta fallido: ya sea a través del mecanismo de reintento de la biblioteca SNMP o a través del mecanismo interno de [procesamiento combinado] (#internal_workings_of_combined_processing) .
Si monitorea dispositivos SNMPv3, asegúrese de que msgAuthoritativeEngineID (también conocido como snmpEngineID o "Engine ID") nunca es compartido por dos dispositivos. Según RFC 2571 (sección 3.1.1.1) debe ser único para cada dispositivo.
RFC3414 requiere que los dispositivos SNMPv3 persistan sus "engineBoots". Algunos dispositivos no hacen eso, lo que resulta en que sus mensajes SNMP se descartan como obsoletos después de reiniciarlos. En tal situación, la caché SNMP debe borrarse manualmente en un servidor/proxy (usando -R snmp_cache_reload) o es necesario reiniciar el servidor/proxy.
Para comenzar a monitorear un dispositivo a través de SNMP, se deben seguir los siguientes pasos:
Descubra la cadena SNMP (u OID) del elemento que desea monitorear.
Para obtener una lista de cadenas SNMP, utilice el comando snmpwalk (parte de net-snmp software que debería tener instalado como parte de la instalación de Zabbix) o herramienta equivalente:
Como '2c' aquí significa versión SNMP, también puede sustituirlo por '1', para indicar SNMP Versión 1 en el dispositivo.
Esto debería darle una lista de cadenas SNMP y su último valor. Si se Entonces es posible que la 'comunidad' SNMP sea diferente de el estándar 'público', en cuyo caso necesitarás averiguar qué es.
Luego puede revisar la lista hasta encontrar la cadena que desea monitor, p.e. si desea monitorear los bytes que ingresan a su Encienda el puerto 3, usaría la cadena IF-MIB::ifHCInOctets.3
de esta línea:
Ahora puede utilizar el comando snmpget para averiguar el OID numérico para 'IF-MIB::ifHCInOctets.3':
Tenga en cuenta que el último número de la cadena es el número de puerto que está buscando monitorear. Ver también: Dinámico índices.
Esto debería darte algo como lo siguiente:
Nuevamente, el último número del OID es el número de puerto.
Algunos de los OID SNMP más utilizados son traducido automáticamente a un número representación por Zabbix.
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_CONTADOR, ASN_CONTADOR64, 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 salida snmpget, pero también podría mostrarse como "STRING", "Hex-STRING", "OID" y otros, dependiendo de la presencia de una sugerencia en pantalla.
Crear un host correspondiente a un dispositivo.
Agregue una interfaz SNMP para el host:
discovery[]
y walk[]
en SNMPv2 y v3. Tenga en cuenta que establecer este valor demasiado alto puede causar que se agote el tiempo de espera de verificación del agente SNMP.Parámetro SNMPv3 | Descripción |
---|---|
Nombre del contexto | Ingrese el nombre del 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, no el protocolo de privacidad AuthPriv - se utilizan protocolos de autenticación y privacidad |
Protocolo de autenticación | Seleccione el protocolo de autenticación: MD5, SHA1, 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). Tenga en cuenta que: - en algunos sistemas más antiguos, es posible que net-snmp no admita AES256; - en algunos sistemas más nuevos (por ejemplo, RHEL9), es posible que se elimine la compatibilidad con DES para el paquete net-snmp. |
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, autenticación protocolo/frase de contraseña, protocolo de privacidad):
::: nota de advertencia Cambios en el Protocolo de autenticación, Frase de contraseña de autenticación, Protocolo de privacidad o Frase de contraseña de privacidad, realizado sin cambiar el nombre de seguridad, entrará en vigor sólo después el caché en un servidor/proxy se borra manualmente (usando -R snmp_cache_reload) o el Se reinicia el servidor/proxy. En los casos en los que Nombre de seguridad también sea cambiado, todos los parámetros se actualizarán inmediatamente. :::
Puede utilizar una de las plantillas SNMP proporcionadas que agregará automáticamente un conjunto de elementos. Antes de usar una plantilla, verifique que sea compatible con el host.
Haga clic en Agregar para guardar el host.
Cree una métrica para monitorear.
Ahora, regrese a Zabbix y haga clic en Métricas 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 asociadas 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:
Parámetro | Descripción |
---|---|
Nombre | Ingrese el nombre de la métrica. |
Tipo | Seleccione agente SNMP aquí. |
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 de la maestra 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 descubrimiento de SNMP. get[OID]: recupera un valor único 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 único para recuperar un valor único 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 general:
Parámetro | Descripción |
---|---|
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:
Monitoreo del tiempo de actividad:
Parámetro | Descripción |
---|---|
OID | MIB::sysUpTime.0 |
Clave | router.uptime |
Tipo de valor | Flotante |
Unidades | tiempo de actividad |
Paso de preprocesamiento: Multiplicador personalizado | 0.01 |
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 Zabbix 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.
El servidor y el proxy de Zabbix pueden consultar los dispositivos SNMP para múltiples valores en una sola solicitud. Esto afecta a varios tipos de SNMP. elementos:
Todos los elementos SNMP en una única interfaz con parámetros idénticos son programado para ser consultado al mismo tiempo. Los dos primeros tipos de artículos. son tomadas por los encuestadores en lotes de como máximo 128 elementos, mientras que los encuestadores de bajo nivel Las reglas de descubrimiento se procesan individualmente, como antes.
En el nivel inferior, se realizan dos tipos de operaciones para consultar valores: obtener múltiples objetos especificados y recorrer un OID árbol.
Para "obtener", se utiliza una PDU GetRequest con como máximo 128 variables. fijaciones. Para "caminar", se utiliza una PDU GetNextRequest para SNMPv1 y GetBulkRequest con campo "max-repetitions" de como máximo 128 se utiliza para SNMPv2 y SNMPv3.
Por lo tanto, los beneficios del procesamiento combinado para cada tipo de elemento SNMP son se describe a continuación:
Sin embargo, existe un problema técnico que no todos los dispositivos son capaces de devolviendo 128 valores por solicitud. Algunos siempre devuelven una respuesta adecuada, pero otros responden con un error "tooBig(1)" o no responden en todo una vez que la respuesta potencial supera un cierto límite.
Para encontrar un número óptimo de objetos para consultar para un determinado dispositivo, Zabbix utiliza la siguiente estrategia. Comienza con cautela con consultando 1 valor en una solicitud. Si tiene éxito, consulta 2 valores en una solicitud. Si esto vuelve a tener éxito, consulta 3 valores en una solicitud y continúa de manera similar multiplicando el número de consultas objetos en 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), Zabbix hace dos cosas.
Primero, para el lote de artículos actual, se reduce a la mitad el número de objetos en un Solicitud única y consultas de 21 variables. Si el dispositivo está vivo, entonces la consulta debería funcionar en la gran mayoría de los casos, porque 28 Se sabía que las variables funcionaban y 21 es significativamente menos que eso. Sin embargo, si eso aún falla, entonces Zabbix vuelve a consultar los valores. uno a uno. Si aún falla en este punto, entonces el dispositivo está Definitivamente no respondo y el tamaño de la solicitud no es un problema.
Lo segundo que hace Zabbix para los lotes de artículos siguientes es iniciar con el último número exitoso de variables (28 en nuestro ejemplo) y continúa incrementando el tamaño de las solicitudes en 1 hasta alcanzar el límite. Para Por ejemplo, asumiendo que el tamaño de respuesta más grande es de 32 variables, el Las solicitudes posteriores serán de tallas 29, 30, 31, 32 y 33. La última la solicitud fallará y Zabbix nunca emitirá una solicitud de tamaño 33 de nuevo. A partir de ese momento, Zabbix consultará como máximo 32 variables para este dispositivo.
Si las consultas grandes fallan con este número de variables, puede significar que una de dos cosas. Los criterios exactos que utiliza un dispositivo para limitar la respuesta. No se puede conocer el tamaño, pero tratamos de aproximarlo usando el número de variables. Entonces la primera posibilidad es que este número de variables sea 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 perdió. Por estos motivos, si Zabbix recibe una consulta fallida, reduce el número máximo de variables para intentar profundizar en el alcance cómodo del dispositivo, pero sólo hasta dos veces.
En el ejemplo anterior, si falla una consulta con 32 variables, Zabbix reducirá la cuenta a 31. Si eso también falla, Zabbix reducirá la cuenta a 30. Sin embargo, Zabbix no reducirá la cuenta por debajo de 30, porque asumirá que más fallas se deben a UDP paquetes que se pierden, en lugar del límite del dispositivo.
Sin embargo, si un dispositivo no puede manejar solicitudes combinadas adecuadamente para otros razones y la heurística descrita anteriormente no funciona, existe una opción "Usar solicitudes combinadas" configuración para cada interfaz que permite deshabilitar las solicitudes combinadas para ese dispositivo.