Table of Contents
2 Agente SNMP
Descripción general
Es posible que desee utilizar la monitorización SNMP en dispositivos como impresoras, switches de red, routers o SAI que normalmente tienen habilitado SNMP y en los que sería poco práctico intentar instalar sistemas operativos completos y agentes Zabbix.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, el servidor Zabbix debe estar configurado inicialmente con soporte SNMP especificando la opción --with-net-snmp. También se recomienda instalar archivos MIB para garantizar que los valores de las métricas se muestren en el formato correcto. Sin los archivos MIB, pueden producirse problemas de formato, como mostrar valores en HEX en lugar de UTF-8 o viceversa.
Las comprobaciones SNMP se realizan únicamente sobre el protocolo UDP.
Los demonios del servidor y proxy de Zabbix registran líneas similares a la siguiente si reciben una respuesta SNMP incorrecta:
Aunque no cubren todos los casos problemáticos, son útiles para identificar dispositivos SNMP individuales para los que se deben deshabilitar las solicitudes combinadas.
El servidor/proxy de Zabbix siempre reintentará al menos una vez después de un intento de consulta fallido: ya sea a través del mecanismo de reintentos de la biblioteca SNMP o mediante el mecanismo interno de procesamiento combinado.
Si monitoriza dispositivos SNMPv3, asegúrese de que msgAuthoritativeEngineID (también conocido como snmpEngineID o "Engine ID") nunca sea 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 lo hacen, lo que provoca que sus mensajes SNMP se descarten como obsoletos después de reiniciarse. En tal situación, la caché SNMP debe borrarse manualmente en un servidor/proxy (utilizando -R snmp_cache_reload) o es necesario reiniciar 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
Averigüe la cadena SNMP (u OID) de la métrica que desea monitorizar.
Para obtener una lista de cadenas SNMP, utilice 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 de SNMP, también puede sustituirlo por '1', para indicar la versión 1 de SNMP en el dispositivo.
Esto debería proporcionarle 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.
A continuación, puede revisar la lista hasta encontrar la cadena que desea monitorizar, por ejemplo, si desea monitorizar los bytes que entran en su switch en el puerto 3, utilizaría la cadena IF-MIB::ifHCInOctets.3 de esta línea:
Ahora puede utilizar el comando snmpget para averiguar el OID numérico de 'IF-MIB::ifHCInOctets.3':
Tenga en cuenta que el último número de la cadena es el número de puerto que desea monitorizar. Consulte también: Índices dinámicos.
Esto debería devolverle algo como lo siguiente:
De nuevo, el último número del OID es el número de puerto.
Algunos de los OID 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 soportados 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, dependiendo de la presencia de una sugerencia de visualización.
Paso 2
Crear 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 requieren solo la comunidad (generalmente 'public')
- SNMPv3 requiere opciones más específicas (ver más abajo)
- Especifique el valor de repetición máxima (por defecto: 10) para solicitudes nativas SNMP bulk (GetBulkRequest-PDUs); solo para métricas
discovery[]ywalk[]en SNMPv2 y v3. Tenga en cuenta que establecer este valor demasiado alto puede causar que la comprobación del agente SNMP exceda el tiempo de espera. - Marque la casilla Usar solicitudes combinadas para permitir el procesamiento combinado de solicitudes SNMP (no relacionado con las solicitudes nativas SNMP bulk "walk" y "get")
| Parámetro SNMPv3 | Descripción |
|---|---|
| Nombre de contexto | Ingrese el nombre de contexto para identificar la métrica 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 privacidad AuthNoPriv - se utiliza protocolo de autenticación, no de privacidad AuthPriv - se utilizan ambos protocolos de autenticación y privacidad |
| Protocolo de autenticación | Seleccione el protocolo de autenticación - MD5, SHA1; con net-snmp 5.8 y versiones más recientes SHA224, SHA256, SHA384 o SHA512. |
| Frase de autenticación | Ingrese la frase 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 privacidad | Ingrese la frase de privacidad. Las macros de usuario se resuelven en este campo. |
En caso de credenciales SNMPv3 incorrectas (nombre de seguridad, protocolo/frase de autenticación, protocolo de privacidad):
- Zabbix recibe un ERROR de net-snmp, excepto por una Frase de privacidad incorrecta, en cuyo caso Zabbix recibe un error de TIMEOUT de net-snmp;
- La disponibilidad de la interfaz SNMP cambiará a rojo (no disponible).
Los cambios en el Protocolo de autenticación, Frase de autenticación, Protocolo de privacidad o Frase de privacidad, realizados sin cambiar el Nombre de seguridad, tendrán efecto solo después de que la caché en un servidor/proxy se borre manualmente (usando -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á automáticamente un conjunto de métricas. Antes de usar una plantilla, verifique que sea compatible con el equipo.
Haga clic en Agregar para guardar el equipo.
Compatibilidad con protocolos de privacidad
Dependiendo de su 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 recientes (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 forma predeterminada en sistemas operativos anteriores a RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.
Para comprobar si la biblioteca net-snmp admite AES192+, utilice una de las siguientes opciones:
net-snmp-config:net-snmp-config --configure-options
Si la salida contiene --enable-blumenthal-aes, AES192+ es compatible.
Tenga en cuenta que net-snmp-config forma parte del paquete de desarrollo para SNMP (libsnmp-dev para Debian/Ubuntu, net-snmp-devel para CentOS/RHEL/OL/SUSE) y puede que no esté instalado por defecto.
snmpget:snmpget -v 3 -x AES-256
Si la salida contiene Invalid privacy protocol specified after -3x flag: AES-256, AES192+ no es compatible. Si la salida contiene No hostname specified., AES192+ no es compatible.
Si su biblioteca net-snmp no admite los 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 monitorización.
Ahora, vuelva 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 simplemente una lista vacía. Supondremos que va a crear la métrica usted mismo utilizando la información que acaba de recopilar usando snmpwalk y snmpget, así que haga clic en Crear métrica.
Complete los parámetros requeridos en el nuevo formulario de métrica:
| Parámetro | Descripción |
|---|---|
| Nombre | Introduzca el nombre de la métrica. |
| Tipo | Seleccione Agente SNMP aquí. |
| Clave | Introduzca la clave como algo significativo. |
| Interfaz de equipo | Asegúrese de seleccionar la interfaz SNMP, por ejemplo, de su switch/router. |
| SNMP OID | Utilice uno de los formatos admitidos para introducir el valor 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 utiliza peticiones SNMP bulk nativas (GetBulkRequest-PDUs) de forma asíncrona. La configuración de timeout para esta métrica puede establecerse en el formulario de configuración de la métrica. Considere establecer un valor de timeout bajo para evitar largos retrasos si el dispositivo no está disponible, ya que se realizarán hasta 5 reintentos si los anteriores expiran o fallan (por ejemplo, un timeout de 3 segundos puede resultar en un tiempo de espera de 15 segundos). Puede usar esto como la métrica principal, con métricas dependientes que extraen datos de la principal usando preprocesamiento. Es posible especificar múltiples OIDs en un solo snmp walk, como walk[OID1,OID2,...] para procesar asíncronamente un OID a la vez.Si la petición bulk no devuelve resultados, se intenta recuperar un solo registro sin petición bulk. Se admiten nombres MIB 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 OIDs/MIBs, es decir, walk[ifDescr,ifType,ifPhysAddress], entonces la salida es una lista concatenada.Las peticiones GetBulk se utilizan con interfaces SNMPv2 y v3 y GetNext para interfaces SNMPv1; las repeticiones máximas para peticiones bulk se configuran a nivel de interfaz. El parámetro de repeticiones máximas afecta a las peticiones bulk determinando el número máximo de OIDs devueltos en una sola respuesta bulk. Un valor más alto da como resultado respuestas bulk más grandes, reduciendo el número de transmisiones requeridas. Sin embargo, no todos los dispositivos pueden admitir valores muy altos, lo que podría causar problemas. Esta métrica devuelve la salida de la utilidad snmpwalk con los parámetros -Oe -Ot -On. Puede usar esta métrica como métrica principal en descubrimiento SNMP. get[OID] - recupera un único valor de forma asíncrona. Por ejemplo: get[1.3.6.1.2.1.31.1.1.1.6.3]La configuración de timeout para esta métrica puede establecerse en el formulario de configuración de la métrica. Considere establecer un valor de timeout bajo para evitar largos retrasos si el dispositivo no está disponible, ya que se realizarán hasta 5 reintentos si los anteriores expiran o fallan (por ejemplo, un timeout de 3 segundos puede resultar en un tiempo de espera de 15 segundos). OID - (heredado) introduzca un OID textual o numérico único para recuperar un único valor de forma síncrona, opcionalmente combinado con otros valores. Por ejemplo: 1.3.6.1.2.1.31.1.1.1.6.3.Para esta opción, el timeout de comprobación de la métrica será igual al valor establecido en el archivo de configuración del servidor. Se recomienda utilizar métricas walk[OID] y get[OID] para un mejor rendimiento. Todas las métricas walk[OID] y get[OID] se ejecutan de forma asíncrona: no es necesario recibir la respuesta a una solicitud antes de que se inicien otras comprobaciones. La resolución DNS también es asíncrona.La concurrencia máxima de comprobaciones asíncronas es 1000 (definida por MaxConcurrentChecksPerPoller). El número de sondeadores SNMP asíncronos se define por 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 añadir un paso Cambio por segundo en la pestaña Preprocesamiento; de lo contrario, obtendrá el valor acumulativo del dispositivo SNMP en lugar del último cambio. |
Todos los campos obligatorios están marcados con un asterisco rojo.
Ahora guarde la métrica y vaya a Monitorización > Últimos datos 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 usará como referencia para disparadores> Por ejemplo, "my_param". |
Tenga en cuenta que el OID puede proporcionarse en forma numérica o de cadena. Sin embargo, en algunos casos, el OID de cadena debe convertirse a representación numérica. Se puede utilizar la utilidad snmpget para este propósito:
Ejemplo 2
Supervisión del tiempo de actividad:
| Parámetro | Descripción |
|---|---|
| OID | MIB::sysUpTime.0 |
| Clave | router.uptime |
| Tipo de valor | Float |
| Unidades | uptime |
| Paso de preprocesamiento: Multiplicador personalizado | 0.01 |
Solicitudes nativas SNMP bulk
La métrica walk[OID1,OID2,...] permite utilizar la funcionalidad nativa de SNMP para solicitudes bulk (GetBulkRequest-PDUs), disponible en las versiones 2/3 de SNMP.
Una solicitud GetBulk en SNMP ejecuta múltiples solicitudes GetNext y devuelve el resultado en una sola respuesta. Esto puede utilizarse tanto para métricas SNMP regulares como para el descubrimiento SNMP, minimizando los viajes de ida y vuelta por la red.
La métrica SNMP walk[OID1,OID2,...] puede utilizarse como la métrica principal que recopila datos en una sola solicitud, con métricas dependientes que analizan la respuesta según sea necesario utilizando preprocesamiento.
Tenga en cuenta que el uso de solicitudes nativas SNMP bulk no está relacionado con la opción de combinar solicitudes SNMP, que es la propia forma de Zabbix de combinar múltiples solicitudes SNMP (ver la siguiente sección).
Se producirá un reintento para las métricas SNMP bulk para evitar fallos si se pierde uno de los paquetes. El tiempo de espera para las métricas SNMP con get y walk (establecido en el formulario de configuración de la métrica) se establece para toda la sesión. Si se alcanza el tiempo de espera, se producirá un reintento, el tiempo de espera se restablecerá y se reenviará la última solicitud, lo que permitirá continuar la sesión desde la última solicitud si se pierde un solo paquete o llega demasiado tarde. Considere establecer un valor bajo de tiempo de espera para evitar largos retrasos si el dispositivo no está disponible, ya que se realizarán hasta 5 reintentos si los anteriores agotan el tiempo de espera o fallan (por ejemplo, un tiempo de espera de 3 segundos puede resultar en un tiempo de espera de 15 segundos).
Funcionamiento interno del procesamiento combinado
El servidor y el proxy de Zabbix pueden consultar dispositivos SNMP para obtener múltiples valores en una sola solicitud. Esto afecta a varios tipos de métricas SNMP:
- métricas SNMP regulares
- métricas SNMP con índices dinámicos
- reglas de descubrimiento de bajo nivel SNMP
Todas las métricas SNMP en una sola interfaz con parámetros idénticos se programan para ser consultadas al mismo tiempo. Los dos primeros tipos de métricas son tomadas por los pollers en lotes de un máximo de 128 métricas, mientras que las reglas de descubrimiento de bajo nivel se procesan individualmente, como antes.
A un nivel inferior, existen dos tipos de operaciones realizadas para consultar valores: obtener múltiples objetos especificados y recorrer un árbol OID.
Para "obtener", se utiliza un GetRequest-PDU con un máximo de 128 enlaces de variables. Para "recorrer", se utiliza un GetNextRequest-PDU para SNMPv1 y GetBulkRequest con el 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 métrica SNMP se describen a continuación:
- las métricas SNMP regulares se benefician de las mejoras en "obtener";
- las métricas SNMP con índices dinámicos se benefician tanto de las mejoras en "obtener" como en "recorrer": "obtener" se utiliza para la verificación del índice y "recorrer" para construir la caché;
- las reglas de descubrimiento de bajo nivel SNMP se benefician de las mejoras en "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 cierto límite.
Para encontrar un número óptimo de objetos a consultar para un dispositivo dado, Zabbix utiliza la siguiente estrategia. Comienza cautelosamente consultando 1 valor en una solicitud. Si tiene éxito, consulta 2 valores en una solicitud. Si vuelve a tener éxito, consulta 3 valores en una solicitud y continúa de manera similar multiplicando el número 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.
Primero, para el lote actual de métricas, reduce a la mitad el número 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 aún falla, entonces Zabbix vuelve a consultar los valores uno por uno. Si aún falla en este punto, entonces el dispositivo definitivamente no responde y el tamaño de la solicitud no es un problema.
La segunda cosa que Zabbix hace para los siguientes lotes de métricas es comenzar con el último número exitoso de variables (28 en nuestro ejemplo) y continuar incrementando los tamaños de solicitud de uno en uno hasta que se alcance el límite. Por ejemplo, suponiendo que el tamaño máximo de respuesta sea de 32 variables, las solicitudes posteriores 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 este número de variables, puede significar una de dos cosas. No se pueden conocer los criterios exactos que utiliza un dispositivo para limitar el tamaño de la respuesta, pero intentamos aproximarlo utilizando el número de variables. Por lo tanto, la primera posibilidad es que este número de variables esté cerca del límite real de tamaño de respuesta del dispositivo en el caso general: a veces la respuesta es menor que el límite, a veces es mayor. La segunda posibilidad es que un paquete UDP en cualquier dirección simplemente se haya perdido. Por estas razones, si Zabbix obtiene una consulta fallida, reduce el número máximo de variables para intentar entrar más 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 conteo a 31. Si eso también falla, Zabbix reducirá el conteo a 30. Sin embargo, Zabbix no reducirá el conteo 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, existe una opción "Usar solicitudes combinadas" para cada interfaz que permite desactivar las solicitudes combinadas para ese dispositivo.
Además, si la interfaz se vuelve frecuentemente no disponible, puede ser necesario aumentar el parámetro UnavailableDelay en los archivos de configuración del servidor Zabbix o proxy Zabbix para reducir la frecuencia de las solicitudes. Las métricas pueden quedar no soportadas si se reciben datos parciales durante el descubrimiento o los recorridos de OID.