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 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, rl servidor Zabbix debe ser configurado inicialmente con la 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 consultan los dispositivos SNMP en busca de múltiples valores en una sola solicitud. Esto afecta a todo tipo de métricas SNMP (métricas SNMP normales, métricas SNMP con índices dinámicos y descubrimiento SNMP de bajo nivel) y debería hacer que el procesamiento SNMP sea mucho más eficiente. Ver la sección [procesamiento masivo] (#funcionamiento-interno-de-procesamiento-masivo) para detalles de información técnica sobre cómo funciona internamente. Las solicitudes masivas también se pueden desactivar para dispositivos que no pueden manejarlos correctamente usando la opción "Usar datos masivos". "Solicitudes" para cada interfaz.
El servidor Zabbix y los demonios proxy registran líneas similares a las siguientes si reciben una respuesta SNMP incorrecta:
Si bien no cubren todos los casos problemáticos, son útiles para identificar dispositivos SNMP individuales para los cuales se deben realizar solicitudes masivas desactivado.
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 procesamiento masivo interno.
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.
Configuración de la supervisión de SNMP
Para comenzar a monitorear un dispositivo a través de SNMP, se deben seguir los siguientes pasos:
Paso 1
Averigüe 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 debe tener 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 darle una lista de cadenas SNMP y su último valor. Si no lo hace, entonces es posible que la 'comunidad' SNMP sea diferente del valor estándar 'public' , en cuyo caso deberá averiguar qué valor tiene.
A continuación, puede recorrer la lista hasta que encuentre la cadena que desea monitorear, por ej. si desea monitorear los bytes que ingresan a su conmutador de red por el puerto 3, usaría la cadena IF-MIB::ifInOctets.3 de esta línea:
Ahora puede usar el comando snmpget para averiguar el OID numérico para 'IF-MIB::ifInOctets.3':
Tenga en cuenta que el último número de la cadena es el número de puerto que está buscando monitorear. Véase 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 puede 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 credenciales de interfaz según la versión SNMP seleccionada:
- SNMPv1, v2 requiere sólo la comunidad (normalmente 'public')
- SNMPv3 requiere opciones más específicas (ver más abajo)
- Deje marcada la casilla Usar solicitudes masivas para permitir solicitudes masivas en el procesamiento de solicitudes SNMP
| Parámetro SNMPv3 | Descripción |
|---|---|
| Nombre de contexto | Ingrese el nombre de contexto para identificar el elemento en la subred SNMP. Nombre de contexto es compatible con elementos SNMPv3 desde Zabbix 2.2. 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):
- Zabbix recibe un ERROR de net-snmp, excepto por una frase de contraseña de privacidad incorrecta, en cuyo caso Zabbix recibe un error de TIEMPO DE ESPERA de net-snmp;
- (desde Zabbix 6.0.13) La disponibilidad de la interfaz SNMP cambiará a rojo (no disponible).
Los cambios en el Protocolo de autenticación, Frase de contraseña de autenticación, Protocolo de privacidad o Frase de contraseña de privacidad, realizados sin cambiar el Nombre de seguridad, entrarán en vigor sólo después de que el caché en un servidor/proxy se borre manualmente (usando -R snmp_cache_reload) o el servidor/proxy se reinicie. 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 (Plantilla de dispositivo SNMP y otros) que agregarán automáticamente un conjunto de métricas. sin embargo, es posible que la plantilla no sea compatible con el equipo. Haga clic en Agregar para guardar el equipo.
Paso 3
Cree una métrica para monitorear.
Entonces, ahora regrese a Zabbix y haga clic en Métricas para el equipo SNMP que ha creado anteriormente. Dependiendo de si usó una plantilla o no cuando creó su equipo, tendrá una lista de métricas SNMP asociadas con su equipo o simplemente una lista vacía. Trabajaremos sobre la suposición que va a crear la métrica usted mismo utilizando la información que se acaba de reunir usando snmpwalk y snmpget, así que haga clic en Crear métrica. En el formulario de nueva métrica:
- Ingrese el nombre de la métrica
- Cambie el campo 'Tipo' a 'Agente SNMP'
- Ingrese la 'Clave' como algo significativo, p. SNMP-InOctets-Bps
- Asegúrese de que el campo 'Interfaz de equipo' tenga su conmutador/enrutador en él
- Ingrese el OID textual o numérico que recuperó anteriormente en el campo 'SNMP OID', por ejemplo: .1.3.6.1.2.1.2.2.1.10.3
- Establezca el 'Tipo de información' en Numérico (flotante)
- Ingrese un 'Intervalo de actualización' y un período de 'Almacenamiento de historial' si lo desea que sean diferentes de los predeterminados
- En la pestaña Preprocesamiento, agregue un paso Cambio por segundo (importante, de lo contrario obtendrá valores acumulativos del dispositivo SNMP en lugar del último cambio). Elija un multiplicador personalizado si quiere uno.
Todos los campos de entrada obligatorios están marcados con un asterisco rojo.
Ahora guarde la métrica y vaya a Monitoreo → Últimos datos para su ver 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 |
Funcionamiento interno del procesamiento masivo
El servidor y el proxy Zabbix consultan los dispositivos SNMP para múltiples valores en una sola solicitud. Esto afecta a varios tipos de métricas SNMP.
- métricas SNMP normales
- métricas SNMP con índices dinámicos
- SNMP reglas de descubrimiento de bajo nivel
Todas las métricas SNMP en una única interfaz con parámetros idénticos son programadas para ser consultadas al mismo tiempo. Los dos primeros tipos de métricas son tomadas por los sondeadores en lotes de como máximo 128 elementos, mientras que en los sondeadores 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 árbol OID.
Para "obtener", se utiliza una PDU GetRequest con como máximo 128 variables fijas. 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 masivo para cada tipo de métrica SNMP se describen a continuación:
- Las métricas SNMP normales se benefician de "obtener" mejoras;
- Las métricas SNMP con índices dinámicos se benefician tanto de "obtener" como de mejoras "caminando": "obtener" se utiliza para la verificación del índice y "caminar" para construir el caché;
- Las reglas de descubrimiento de bajo nivel SNMP se benefician de mejoras en "caminar".
Sin embargo, existe un problema técnico que 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 del 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 consultando 1 valor en una solicitud. Si tiene éxito, consulta 2 valores en una solicitud. Si eso 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 métricas actual, se reduce a la mitad el número de objetos en una 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 con 28 se sabía que las variables funcionaban y 21 es significativamente menos que eso. Sin embargo, si esto aún falla, Zabbix vuelve a consultar los valores uno a 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.
Lo segundo que hace Zabbix para los lotes de métricas 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. Por ejemplo, asumiendo que el tamaño de respuesta más grande es de 32 variables, las solicitudes posteriores serán de tamaños 29, 30, 31, 32 y 33. La última 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 esta cantidad de variables, puede significar 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 rango cómodo del dispositivo, pero (a partir de 2.2.8) solo 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 masivas adecuadamente para otros razones y la heurística descrita anteriormente no funciona, ya que Zabbix 2.4 hay una configuración de "Usar solicitudes masivas" para cada interfaz que permite deshabilitar las solicitudes masivas para ese dispositivo.