SNMP agent
Resumen
Es posible que desee utilizar la supervisión SNMP en dispositivos como impresoras, conmutadores de red, routers o UPS que normalmente tienen SNMP habilitado y en los que sería poco práctico intentar instalar sistemas operativos completos y agentes de Zabbix.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, Zabbix server debe estar configurado inicialmente con compatibilidad SNMP, especificando la opción --with-net-snmp.
Se recomienda también instalar archivos MIB para garantizar que los valores de los item 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.
Zabbix server y los demonios proxy registran líneas similares a la siguiente si reciben una respuesta SNMP incorrecta:
SNMP response from host "gateway" does not contain all of the requested variable bindingsAunque no cubren todos los casos problemáticos, son útiles para identificar dispositivos SNMP individuales para los que deben deshabilitarse las solicitudes combinadas.
Zabbix server/proxy reintentará hasta 5 veces los item walk y get de SNMP.
El mecanismo de reintento no se aplica a los fallos de resolución DNS.
Para las comprobaciones SNMP heredadas (número OID único o cadena), Zabbix server/proxy reintentará al menos una vez después de un intento de consulta fallido: ya sea mediante el mecanismo de reintento de la biblioteca SNMP o mediante el mecanismo interno de procesamiento combinado.
Si supervisa dispositivos SNMPv3, asegúrese de que msgAuthoritativeEngineID (también conocido como snmpEngineID o "Engine ID") nunca se comparta entre dos dispositivos. Según RFC 2571 (sección 3.1.1.1), debe ser único para cada dispositivo.
RFC3414 requiere que los dispositivos SNMPv3 conserven 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, es necesario limpiar manualmente la caché SNMP en un server/proxy (usando -R snmp_cache_reload) o reiniciar el server/proxy.
Zabbix almacena en caché las asignaciones SNMPv3 EngineID → IP y reutiliza los EngineID almacenados en caché para comprobaciones posteriores en lugar de enviar una sonda cada vez, reduciendo así el tráfico de red. Si no se puede reutilizar un EngineID, se realizará un reintento con una sonda para descubrir el nuevo EngineID.
Configuración de la monitorización SNMP
Para comenzar a monitorizar un dispositivo a través de SNMP, deben realizarse los siguientes pasos:
Paso 1
Averigüe la cadena SNMP (o OID) del item que desea supervisar.
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:
snmpwalk -v 2c -c public <host IP> .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 devolverle una lista de cadenas SNMP y su último valor.
Si no es así, es posible que la "community" de SNMP sea distinta de la estándar public, en cuyo caso deberá averiguar cuál es.
A continuación, puede recorrer la lista hasta encontrar la cadena que desea supervisar; por ejemplo,
si quisiera supervisar los bytes entrantes en su switch por el puerto 3, usaría la cadena IF-MIB::ifHCInOctets.3 de esta línea:
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121Ahora puede usar el comando snmpget para averiguar el OID numérico de IF-MIB::ifHCInOctets.3:
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3Tenga en cuenta que el último número de la cadena es el número de puerto que desea supervisar. Véase también: Índices dinámicos.
Esto debería devolverle algo como lo siguiente:
.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941De 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 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 pista de visualización.
Paso 2
Crear un host correspondiente a un dispositivo.
Añada una interfaz SNMP para el host:
- Introduzca la dirección IP/nombre DNS y el número de puerto.
- Seleccione la versión SNMP en la lista desplegable.
- Añada las credenciales de la interfaz según la versión SNMP seleccionada:
- SNMPv1 y v2 requieren solo la comunidad (normalmente 'public').
- SNMPv3 requiere opciones más específicas; consulte SNMPv3.
- Especifique el valor máximo de repeticiones (predeterminado: 10) para solicitudes bulk SNMP nativas (GetBulkRequest-PDUs); solo para items
discovery[]ywalk[]en SNMPv2 y v3. Tenga en cuenta que establecer este valor demasiado alto puede provocar que se agote el tiempo de espera de la comprobación del agent SNMP. - Marque la casilla Usar solicitudes combinadas para permitir el procesamiento combinado de solicitudes SNMP (no relacionado con las solicitudes bulk SNMP nativas "walk" y "get").
Puede usar una de las templates SNMP proporcionadas, que añadirá automáticamente un conjunto de items. Antes de usar una template, verifique que sea compatible con el host.
Haga clic en Añadir para guardar el host.
SNMPv3
Los siguientes parámetros son obligatorios para SNMPv3:
- Context name - Introduzca el nombre de contexto para identificar el item en la subred SNMP.
Las macros de usuario se resuelven en este campo. - Security name - Introduzca el nombre de seguridad.
Las macros de usuario se resuelven en este campo. - Security level - Seleccione el nivel de seguridad:
- noAuthNoPriv - no se usan protocolos de autenticación ni de privacidad;
- AuthNoPriv - se usa el protocolo de autenticación, pero no el de privacidad;
- AuthPriv - se usan tanto el protocolo de autenticación como el de privacidad.
- Authentication protocol - Seleccione el protocolo de autenticación: MD5, SHA1; con net-snmp 5.8 y versiones posteriores, SHA224, SHA256, SHA384 o SHA512.
- Authentication passphrase - Introduzca la frase de contraseña de autenticación.
Las macros de usuario se resuelven en este campo. - Privacy protocol - Seleccione el protocolo de privacidad: DES, AES128, AES192, AES256, AES192C (Cisco) o AES256C (Cisco).
Consulte las notas sobre compatibilidad con el protocolo de privacidad. - Privacy passphrase - Introduzca la frase de contraseña de privacidad.
Las macros de usuario se resuelven en este campo.
En caso de credenciales SNMPv3 incorrectas (security name, authentication protocol/passphrase, privacy protocol):
- Zabbix recibe un ERROR de net-snmp, excepto en el caso de una Privacy passphrase incorrecta, en cuyo caso Zabbix recibe un error TIMEOUT de net-snmp.
- La disponibilidad de la interfaz SNMP cambiará a rojo (no disponible).
Los cambios en Authentication protocol, Authentication passphrase, Privacy protocol o Privacy passphrase, realizados sin cambiar el Security name, normalmente se aplican automáticamente cuando la interfaz SNMPv3 correspondiente se actualiza en Zabbix. En los casos en que también se cambia el Security name, todos los parámetros se actualizarán inmediatamente.
Compatibilidad con protocolos de privacidad
Dependiendo de su sistema operativo y de 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 se admiten de forma predeterminada en 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 admite AES192+, use una de las siguientes opciones:
net-snmp-config:
net-snmp-config --configure-optionsSi 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 de forma predeterminada.
snmpget:
snmpget -v 3 -x AES-256Si 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 y, a continuación, vuelva a compilar el server de Zabbix especificando la opción --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
Paso 3
Cree un item para la monitorización.
Ahora, vuelva a Zabbix y haga clic en Items para el host SNMP que creó anteriormente. Dependiendo de si utilizó un template o no al crear el host, tendrá una lista de items SNMP asociados a su host o simplemente una lista vacía. Supondremos que va a crear el item usted mismo utilizando la información que acaba de recopilar con snmpwalk y snmpget, así que haga clic en Create item.
Complete los parámetros obligatorios en el formulario del nuevo item:
| Parameter | Description |
|---|---|
| Name | Introduzca el nombre del item. |
| Type | Seleccione SNMP agent aquí. |
| Key | Introduzca una clave significativa. |
| Host interface | Asegúrese de seleccionar la interfaz SNMP, por ejemplo, la de su switch/router. |
| SNMP OID | Utilice uno de los formatos compatibles para introducir 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 utiliza solicitudes bulk nativas de SNMP (GetBulkRequest-PDU) de forma asíncrona. La configuración del tiempo de espera para este item puede establecerse en el formulario de configuración del item. Considere establecer un valor de tiempo de espera bajo para evitar demoras prolongadas 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 una espera de 15 segundos). Puede utilizarlo como item maestro, con items dependientes que extraigan datos del item maestro mediante el preprocesamiento. Es posible especificar varios OID en un único snmp walk, como walk[OID1,OID2,...], para procesar cada OID de forma asíncrona.Si la solicitud bulk no devuelve resultados, se intentará recuperar un único registro sin una solicitud bulk. Los nombres MIB son compatibles como parámetros; por lo tanto, walk[1.3.6.1.2.1.2.2.1.2] y walk[ifDescr] devolverán el mismo resultado.Si se especifican varios OID/MIB, es decir, walk[ifDescr,ifType,ifPhysAddress], el resultado será una lista concatenada.Las solicitudes GetBulk se utilizan con interfaces SNMPv2 y v3, y GetNext con interfaces SNMPv1; las repeticiones máximas para las solicitudes bulk se configuran en el nivel de la interfaz. El parámetro de repeticiones máximas afecta a las solicitudes bulk al determinar el número máximo de OID devueltos en una única respuesta bulk. Un valor más alto produce respuestas bulk más grandes, lo que reduce el número de transmisiones necesarias. Sin embargo, es posible que algunos dispositivos no admitan valores muy altos, lo que podría causar problemas. Este item devuelve el resultado de la utilidad snmpwalk con los parámetros -Oe -Ot -On. Puede utilizar este item como item maestro en el descubrimiento SNMP. get[OID]: recupera un valor único de forma asíncrona. Por ejemplo: get[1.3.6.1.2.1.31.1.1.1.6.3]La configuración del tiempo de espera para este item puede establecerse en el formulario de configuración del item. Considere establecer un valor de tiempo de espera bajo para evitar demoras prolongadas 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 una espera de 15 segundos). OID: (heredado) introduzca un único OID textual o numérico para recuperar un valor único 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 tiempo de espera de la comprobación del item será igual al valor establecido en el archivo de configuración del server. Se recomienda utilizar items walk[OID] y get[OID] para obtener un mejor rendimiento. Todos los items walk[OID] y get[OID] se ejecutan de forma asíncrona; no es necesario recibir la respuesta a una solicitud antes de iniciar otras comprobaciones. La resolución DNS también es asíncrona.La concurrencia máxima de las comprobaciones asíncronas es 1000 (definida por MaxConcurrentChecksPerPoller). El número de pollers SNMP asíncronos 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, debe añadirse un paso Change per second en la pestaña Preprocessing; de lo contrario, obtendrá el valor acumulado del dispositivo SNMP en lugar del cambio más reciente. |
Todos los campos de entrada obligatorios están marcados con un asterisco rojo.
Ahora guarde el item y vaya a Monitoring > Latest data para consultar los 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 disparadores> Por ejemplo, "mi_param". |
Tenga en cuenta que el OID puede darse 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:
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0Ejemplo 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
El walk[OID1,OID2,...] item 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 items SNMP regulares como para el descubrimiento SNMP para minimizar los viajes de ida y vuelta en la red.
El item SNMP walk[OID1,OID2,...] puede utilizarse como el item maestro que recopila datos en una sola solicitud con items 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 realizarán hasta cinco reintentos para los items SNMP bulk para evitar fallos si se pierde uno de los paquetes.
El tiempo de espera para los items SNMP con get y walk (establecido en el formulario de configuración del item) se establece para toda la sesión.
El tiempo de espera se aplica independientemente de si los datos se recuperan completamente; si los datos se reciben parcialmente (por ejemplo, los datos se recopilan correctamente solo para uno de varios OID), entonces el item se vuelve no soportado con el mensaje "Only partial data received".
Si se alcanza el tiempo de espera, se producirá un reintento, el tiempo de espera se restablecerá y la última solicitud se reenviará, 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 de tiempo de espera bajo para evitar largos retrasos si el dispositivo no es accesible, 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 server y el proxy de Zabbix pueden consultar dispositivos SNMP para obtener varios valores en una sola solicitud. Esto afecta a varios tipos de items SNMP:
- items SNMP normales
- items SNMP con índices dinámicos
- reglas de descubrimiento de bajo nivel SNMP
Todos los items SNMP de una misma interfaz con parámetros idénticos se programan para consultarse al mismo tiempo. Los dos primeros tipos de items son tomados por los pollers en lotes de un máximo de 128 items, mientras que las reglas de descubrimiento de bajo nivel se procesan individualmente, como antes.
En un nivel inferior, se realizan dos tipos de operaciones para consultar valores: obtener varios objetos especificados y recorrer un árbol de OID.
Para la operación de "obtención", se utiliza un GetRequest-PDU con un máximo de 128 vinculaciones de variables. Para la operación de "recorrido", se utiliza un GetNextRequest-PDU para SNMPv1 y un GetBulkRequest con el campo "max-repetitions" establecido en un máximo de 128 para SNMPv2 y SNMPv3.
Por lo tanto, las ventajas del procesamiento combinado para cada tipo de item SNMP son las siguientes:
- los items SNMP normales se benefician de las mejoras de la "obtención";
- los items SNMP con índices dinámicos se benefician de las mejoras tanto de la "obtención" como del "recorrido": la "obtención" se utiliza para verificar el índice y el "recorrido" para crear la caché;
- las reglas de descubrimiento de bajo nivel SNMP se benefician de las mejoras del "recorrido".
Sin embargo, existe un problema técnico: no todos los dispositivos pueden devolver 128 valores por solicitud. Algunos siempre devuelven una respuesta correcta, pero otros responden con un error "tooBig(1)" o no responden en absoluto cuando la respuesta potencial supera cierto límite.
Para encontrar un número óptimo de objetos que consultar para un dispositivo determinado, Zabbix utiliza la siguiente estrategia. Comienza de forma prudente consultando 1 valor por solicitud. Si la operación tiene éxito, consulta 2 valores por solicitud. Si vuelve a tener éxito, consulta 3 valores por solicitud y continúa de forma similar, multiplicando el número de objetos consultados por 1,5. Esto 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, cuando un dispositivo rechaza una respuesta correcta (por ejemplo, para 42 variables), Zabbix hace dos cosas.
En primer lugar, para el lote de items actual reduce a la mitad el número de objetos de una sola solicitud y consulta 21 variables. Si el dispositivo está activo, la consulta debería funcionar en la gran mayoría de los casos, porque se sabe que 28 variables funcionan y 21 es una cantidad significativamente menor. Sin embargo, si esto también falla, Zabbix vuelve a consultar los valores uno por uno. Si también falla en este punto, el dispositivo definitivamente no responde y el tamaño de la solicitud no es el problema.
En segundo lugar, para los lotes de items posteriores, Zabbix comienza con el último número de variables que tuvo éxito (28 en nuestro ejemplo) y continúa incrementando el tamaño de las solicitudes en 1 hasta alcanzar el límite. Por ejemplo, suponiendo que el mayor tamaño de respuesta es de 32 variables, las solicitudes posteriores tendrán tamaños de 29, 30, 31, 32 y 33. La última solicitud fallará y Zabbix no 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 aproximarlos utilizando el número de variables. 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 y otras veces es mayor. La segunda posibilidad es que simplemente se haya perdido un paquete UDP en cualquiera de las dos direcciones. Por estos motivos, si Zabbix recibe una consulta fallida, reduce el número máximo de variables que intentará obtener para acercarse más al rango cómodo del dispositivo, pero solo hasta dos veces.
En el ejemplo anterior, si una consulta con 32 variables falla, Zabbix reducirá el número a 31. Si esa consulta también falla, Zabbix reducirá el número a 30. Sin embargo, Zabbix no reducirá el número por debajo de 30, porque supondrá que los fallos posteriores se deben a la pérdida de paquetes UDP y no al límite del dispositivo.
No obstante, si un dispositivo no puede gestionar correctamente las solicitudes combinadas por otros motivos y la heurística descrita anteriormente no funciona, existe una opción Use combined requests para cada interfaz que permite desactivar las solicitudes combinadas para ese dispositivo.
Si las solicitudes combinadas provocan respuestas parciales o con formato incorrecto que dan lugar a cálculos incorrectos por segundo (delta) (por ejemplo, picos aparentes en los contadores de las interfaces), desactive Use combined requests para la interfaz afectada a fin de forzar consultas independientes por item; esto suele evitar picos falsos.
Como alternativa, considere utilizar items asíncronos get[] o walk[], que se ejecutan de forma asíncrona y no están sujetos al procesamiento por lotes de Use combined requests por interfaz; pueden utilizarse en lugar de las comprobaciones de OID síncronas heredadas para evitar problemas relacionados con las solicitudes combinadas.
Busque entradas en los registros del server/proxy similares a la que se muestra en la sección Descripción general para ayudar a identificar los dispositivos afectados.
Además, si la interfaz deja de estar disponible con frecuencia, puede ser necesario aumentar el parámetro UnavailableDelay en los archivos de configuración del server de Zabbix o del proxy de Zabbix para reducir la frecuencia de las solicitudes.
Los items pueden dejar de ser compatibles si se reciben datos parciales durante el descubrimiento o los recorridos de OID.