Documentation
Table of Contents
2 Agente SNMP
Descripción 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 Zabbix.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, el servidor Zabbix 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 Zabbix 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 Zabbix 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 RFC 2571 (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.
Configuración 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 net-snmp que debería haber instalado como parte de la instalación de Zabbix) 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 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_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")
| Parámetro SNMPv3 | Descripción |
|---|---|
| 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):
- Zabbix recibe un ERROR de net-snmp, excepto si la Frase de contraseña de privacidad es incorrecta, en cuyo caso Zabbix 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 Zabbix 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 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 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:
| 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 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 ú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 1
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:
Ejemplo 2
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 |
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 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.
Funcionamiento interno del procesamiento combinado
El servidor y el proxy Zabbix pueden consultar dispositivos SNMP para múltiples valores en una única solicitud. Esto afecta a varios tipos de métricas SNMP:
- Métricas SNMP normales
- Métricas 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, Zabbix 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), Zabbix 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, Zabbix 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 Zabbix 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 Zabbix nunca volverá a emitir una solicitud de tamaño 33. A partir de ese momento, Zabbix 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 Zabbix 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, Zabbix reducirá el recuento a 31. Si eso también falla, Zabbix reducirá el recuento a 30. Sin embargo, Zabbix 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.