Documentation
Table of Contents
2 SNMP agent
Visión general
Es posible que desee utilizar la supervisión de SNMP en dispositivos como impresoras, red conmutadores, 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 de Zabbix.
Para poder recuperar los datos proporcionados por los agentes SNMP en estos dispositivos, El servidor Zabbix debe ser inicialmente configurado con soporte SNMP.
Las comprobaciones de SNMP se realizan únicamente sobre el protocolo UDP.
El servidor Zabbix y los demonios proxy consultan los dispositivos SNMP para múltiples valores en una sola solicitud. Esto afecta a todos los tipos de elementos SNMP (SNMP normal). elementos, elementos SNMP con índices dinámicos y detección de bajo nivel SNMP) y debería hacer que el procesamiento SNMP sea mucho más eficiente. Ver el bulto procesamiento para información técnica detalles sobre cómo funciona internamente. Las solicitudes masivas también se pueden desactivar para dispositivos que no pueden manejarlos adecuadamente usando el "Usar a granel "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 identificación de dispositivos SNMP individuales para los que se deben realizar solicitudes masivas desactivado.
El servidor/proxy de Zabbix siempre volverá a intentarlo al menos una vez después de un intento de consulta fallido: ya sea a través del reintento de la biblioteca SNMP o a través del mecanismo interno a granel procesamiento mecanismo.
::: nota de advertencia Si monitorea dispositivos SNMPv3, asegúrese de que msgAuthoritativeEngineID (también conocido como snmpEngineID o "ID de motor") es nunca compartida por dos dispositivos. Según RFC 2571 (sección 3.1.1.1) debe ser único para cada dispositivo. :::
::: nota de advertencia RFC3414 requiere que los dispositivos SNMPv3 persistan sus botas de motor. Algunos dispositivos no hacen eso, lo que resulta en su Los mensajes SNMP se descartan como obsoletos después de reiniciarse. De tal situación, la caché SNMP debe borrarse manualmente en un servidor/proxy (mediante usando -R snmp_cache_reload) o el servidor/proxy necesita ser reiniciado. :::
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) del elemento que desea monitorear.
Para obtener una lista de cadenas SNMP, use el comando snmpwalk (parte de net-snmp software 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 se entonces es posible que la 'comunidad' SNMP sea diferente de el 'público' estándar, en cuyo caso deberá averiguar qué es.
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 encienda 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: Dinámico índices.
Esto debería darte algo como lo siguiente:
Nuevamente, el último número en el OID es el número de puerto.
3COM parece usar cientos de números de puerto, p. puerto 1 = puerto 101, puerto 3 = puerto 103, pero Cisco usa números regulares, p. puerto 3 = 3.
Algunos de los OID de 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 "Counter32", que internamente corresponde al tipo ASN_COUNTER. 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 (desde 2.2.8, 2.4.3). Estos tipos corresponden aproximadamente a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" en Salida de snmpget, pero también puede mostrarse como "STRING", "Hex-STRING", "OID" y otros, dependiendo de la presencia de una pista de visualización.
Paso 2
Crear un host correspondiente a un dispositivo.
Agregue una interfaz SNMP para el host:
- Ingrese la dirección IP/nombre DNS y el número de puerto
- Seleccione la versión SNMP del menú desplegable
- Agregar credenciales de interfaz según la versión de SNMP seleccionada:
- SNMPv1, v2 requiere solo la comunidad (generalmente 'pública')
- SNMPv3 requiere opciones más específicas (ver más abajo)
- Deje la casilla de verificación Usar solicitudes masivas marcada para permitir solicitudes masivas 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. El 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 privacidad AuthNoPriv: se utiliza el protocolo de autenticación, no se utiliza el protocolo de privacidad AuthPriv - se utilizan tanto los protocolos de autenticación como los de 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). |
| 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 TIMEOUT de net-snmp.
::: nota de advertencia Cambios en Protocolo de autenticación, Frase de contraseña de autenticación, Protocolo de privacidad o Frase de contraseña de privacidad, hecho sin cambiar el Nombre de seguridad, tendrá efecto solo después de el caché en un servidor/proxy se borra manualmente (usando -R snmp_cache_reload) o el el servidor/proxy se reinicia. En los casos en que Nombre de seguridad también modificado, 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 elementos. sin embargo, el la plantilla puede no ser compatible con el host. Haga clic en Agregar para guardar el anfitrión.
Paso 3
Cree un elemento para monitorear.
Entonces, ahora regrese a Zabbix y haga clic en Elementos para el host SNMP que creado anteriormente. Dependiendo de si usó una plantilla o no cuando creando su host, tendrá una lista de elementos SNMP asociados con su anfitrión o simplemente una lista vacía. Trabajaremos sobre la suposición que va a crear el elemento usted mismo utilizando la información que se acaba de reunir usando snmpwalk y snmpget, así que haga clic en Crear artículo. En el formulario de elemento nuevo:
- Ingrese el nombre del artículo
- 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 host' 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 SNMP dispositivo en lugar del último cambio). Elija un multiplicador personalizado si quieres uno.
Todos los campos de entrada obligatorios están marcados con un asterisco rojo.
Ahora guarde el elemento y vaya a Monitoreo → Últimos datos para su SNMP ¡datos!
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 los disparadores> Por ejemplo, "my_param". |
Tenga en cuenta que el OID se puede proporcionar en formato numérico o de cadena. Sin embargo, en algunos casos, la cadena OID debe convertirse a representación numérica. La utilidad snmpget puede usarse para este propósito:
El monitoreo de los parámetros SNMP es posible si el indicador --with-net-snmp fue especificado al configurar las fuentes de Zabbix.
Ejemplo 2
Monitoreo del tiempo de actividad:
| Parámetro | Descripción |
|---|---|
| OID | MIB::sysUpTime.0 |
| Clave | tiempo de actividad del enrutador |
| Tipo de valor | Flotante |
| Unidades | tiempo de actividad |
| Multiplicador | 0.01 |
Native SNMP bulk requests
The walk[OID1,OID2,...] item allows to use native SNMP functionality for bulk requests (GetBulkRequest-PDUs), available in SNMP versions 2/3.
A GetBulk request in SNMP executes multiple GetNext requests and returns the result in a single response. This may be used for regular SNMP items as well as for SNMP discovery to minimize network roundtrips.
The SNMP walk[OID1,OID2,...] item may be used as the master item that collects data in one request with dependent ityems that parse the response as needed using preprocessing.
Note that using native SNMP bulk requests is not related to the option of combining SNMP requests, which is Zabbix own way of combining multiple SNMP requests (see next section).
Funcionamiento interno del procesamiento masivo
A partir de 2.2.3 Servidor Zabbix y dispositivos proxy SNMP consultan múltiples valores en una sola solicitud. Esto afecta a varios tipos de SNMP elementos:
- artículos SNMP regulares
- Elementos SNMP con dinámica índices
- SNMP descubrimiento de bajo nivel reglas
Todos los elementos SNMP en una sola interfaz con parámetros idénticos son programado para ser consultado al mismo tiempo. Los dos primeros tipos de artículos. son tomados por encuestadores en lotes de un máximo de 128 elementos, mientras que los de bajo nivel las reglas de descubrimiento se procesan individualmente, como antes.
En el nivel inferior, hay dos tipos de operaciones realizadas para consultar valores: obtener múltiples objetos especificados y caminar un OID árbol.
Para "obtener", se utiliza una GetRequest-PDU con un máximo de 128 variables ataduras Para "caminar", se usa una GetNextRequest-PDU para SNMPv1 y GetBulkRequest con un campo de "repeticiones máximas" de 128 como máximo se usa para SNMPv2 y SNMPv3.
Por lo tanto, los beneficios del procesamiento masivo para cada tipo de elemento SNMP son se describe a continuación:
- Los elementos regulares de SNMP se benefician de las mejoras "conseguidas";
- Los elementos SNMP con índices dinámicos se benefician tanto de "obtener" como de mejoras de "caminar": "obtener" se utiliza para la verificación de índices y "caminar" para construir el caché;
- Las reglas de descubrimiento de bajo nivel de SNMP se benefician de las mejoras de "caminar".
Sin embargo, hay 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 "demasiado grande (1)" o no responden en todo una vez que la respuesta potencial está por encima de un cierto límite.
Para encontrar un número óptimo de objetos para consultar para un determinado dispositivo, Zabbix utiliza la siguiente estrategia. Comienza cautelosamente con consultando 1 valor en una solicitud. Si eso 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 consultas objetos 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 de artículos actual, reduce a la mitad el número de objetos en un solicitud única y consulta 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 menor que eso. Sin embargo, si eso sigue fallando, entonces Zabbix recurre a consultar valores uno a uno. Si todavía falla en este punto, entonces el dispositivo está definitivamente no responde y el tamaño de la solicitud no es un problema.
Lo segundo que hace Zabbix para los lotes de artículos subsiguientes es que comienza con el último número exitoso de variables (28 en nuestro ejemplo) y continúa incrementando los tamaños de solicitud en 1 hasta que se alcanza el límite. Para ejemplo, suponiendo que el tamaño de respuesta más grande es de 32 variables, el las solicitudes posteriores serán de los tamaños 29, 30, 31, 32 y 33. El último la solicitud fallará y Zabbix nunca emitirá una solicitud de tamaño 33 otra vez. 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 que una de dos cosas. Los criterios exactos que utiliza un dispositivo para limitar la respuesta el tamaño no se puede saber, pero tratamos de aproximarlo usando el número de variables Así que 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 que. La segunda posibilidad es que un paquete UDP en cualquier dirección simplemente se perdió. Por estas razones, si Zabbix obtiene una consulta fallida, reduce al máximo el número de variables para intentar profundizar en el rango cómodo del dispositivo, pero (a partir de 2.2.8) sólo 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 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 correctamente las solicitudes masivas por otras 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.