Documentation
Table of Contents
2 Agtente SNMP
Visi¨®n General
Puede ser necesario monitorear a trav¨¦s de SNMP algunos dispositivos como ser impresoras, switches de red, routers o UPS. Por lo general estos dispositivos tienen habilitado SNMP, o pueden habilitarse en su configuraci¨®n. Esto es muy ¨²til cuando los dispositivos no cuentan con un SO que soporte la instalaci¨®n de, por ejemplo, un agente zabbix.
Para poder cosechar datos mediante SNMP de este tipo de dispositivos, el Áú»¢¶Ä²© server debe ser configurado con soporte SNMP.
Los chequeos SNMP son hechos a trav¨¦s del protocolo UDP ¨²nicamente.
Desde Áú»¢¶Ä²© 2.2.3 los demonios Áú»¢¶Ä²© server y proxies solicitan m¨²ltimples datos SNMP en un solo requerimiento. Esto es as¨ª para todos los items SNMP (simples ¨ªtems SNMP, ¨ªtems SNMP con ¨ªndices din¨¢micos y las SNMP LDD (los level dsicoveries) ) para lograr hacer el proceso de SNMP mucho mas eficiente. Por favor refi¨¦rase a la seccion con detalles t¨¦cnicos mas abajo para entender c¨®mo funciona internamente. Desde Áú»¢¶Ä²© 2.4 hay una opci¨®n de "Use bulk requests" que permite deshabilitar este tipo de pedidos (bulk request) a nivel de interface, para los dispositivos que no puedan manejar este tipo de pedido de manera correcta.
Desde Áú»¢¶Ä²© 2.2.7 y Áú»¢¶Ä²© 2.4.2, los demonios Áú»¢¶Ä²© server y proxy logean lineas similarea a la siguiente si reciben una respuesta SNMP incorrecta:
Aunque no abarquen todos los casos problem¨¢ticos, son ¨²tiles para identificar dispositivos SNMP en los que se deber¨ªa deshabilitar esta opci¨®n.
Desde Áú»¢¶Ä²© 2.2, los demonios Áú»¢¶Ä²© server y proxy utilizan correctamente el seteo del par¨¢metro Timeout cuando cosechan datos SNMP. Adicionalmente, los demonions no insisten luego de obtener un error en un pedido (timeout o error de credenciales). Anteriormente la librer¨ªa SNMP utilizaba los valores por defecto de timeout y reintentos ( 1 segundo, 5 reintentos)
Desde Áú»¢¶Ä²© 2.2.8 y Áú»¢¶Ä²© 2.4.2, los demonios Áú»¢¶Ä²© server y proxy siempre van a reintentar al menos una vez, tanto a trav¨¦s del mecanismo de la librer¨ªs SNMP o a trav¨¦s de mecanismo de procesamiento interno.
Si se est¨¢n monitoreando dispositivos SNMPv3, aseg¨²rese de que msgAuthoritativeEngineID (tambi¨¦n conocido como snmpEngineID o "Engine ID") no se repite en dos dispositivos. De acuerdo con (section 3.1.1.1) debe ser ¨²nico por dispositivo.
Configurando el monitoreo SNMP
Para comenzar a monitorear un dispositivo a trav¨¦s de SNMP, se deben seguir los siguientes pasos.
Paso 1
Crear un host para el dispositivo con una interfaz SNMP.
Ingrese la direcci¨®n IP. Se pueden usar los templates suministrados por zabbix (Template SNMP Device y otros) que van a agregar autom¨¢ticamente un conjunto de ¨ªtems. Sin embargo, el template puede no ser compatible con el host. Click en Add para guardar el host.
Los chequeos SNMP no usan el Agent port, es ignorado.
Paso 2
Buscar el nombre SNMP o el OID del item que se desea chequear.
Para obtener una lista de los nombres SNMP, use el comando snmpwalk (parte de que debe ser instalado cuando se instala Áú»¢¶Ä²© y se desea monitorear mediante SNMP) o una herramienta equivalente:
'2c' es la versi¨®n SNMP, puede ser sustituida por '1', para indicar la vesi¨®n 1 en el dispositivo
Esto debe retornar una lista de los nombres SNMP y su ¨²ltimo valor. Si no es as¨ª, posiblemente la comunity no es el standard 'public', y se deber¨¢ de conseguir este valor para obtener la lista.
Se busca en la lista el nombre del que se quiere obtener el valor para monitorear, por ejemplo, si lo que se quiere es monitorear los bytes entrantes el el switch en el puerto 3, se usar¨¢ IF-MIB::ifInOctets.3 como nombre, en la lista aparecer¨¢ algo como:
Puede usarse el comando snmpget para saber el valor num¨¦rico del OID para 'IF-MIB::ifInOctets.3':
N¨®tese que el ¨²ltimo n¨²mero en el nombre es el puerto al que se quiere hacer referencia. Vea tambi¨¦n: Indices din¨¢micos.
Deber¨ªa retornar algo como:
Nuevamente, el ¨²ltimo n¨²mero en el OID es el puerto al que se quiere hacer referencia.
3COM parece usar los n¨²meros de puerto en los cientos, por ejemplo, puerto 1 = 101, puerto 3 = 103, pero Cisco usar n¨²meros comunes, por ejemplo puerto 3 = 3.
Algunos de los OIDs mas usados son traducidos autom¨¢ticamente a su representaci¨®n num¨¦rica por Áú»¢¶Ä²©.
En el ¨²ltimo ejemplo el tipo de valor es "Counter32", que internamente corresponde a un tipo ASN_COUNTER. La lista completa de los 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 and ASN_OBJECT_ID (desde 2.2.8, 2.4.3). Estos tipos correspoden a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" en la salidad del comando snmpget, pero pueden ser mostrados como "STRING", "Hex-STRING", "OID" y otros, dependiendo de la existencia de un display hint
Paso 3
Crear un item para monitorear.
En el host creado anteriormente, ir a Items. Dependiendo si se us¨® un template o no cuando se cre¨® el host, se puede tener una lista de ¨ªtems asociados al host o una lista vac¨ªa de ¨ªtems. Vamos a trabajar asumiendo que vamos a crear el ¨ªtem, utilizando la informaci¨®n obtenida con los comandos snmpwalk y snmpget. Cliqueamos en Create Item. En el formulario desplegado, ingresamos el nombre del item. Aseg¨²rese de que el campo de interface tiene la IP de dispositivo a monitorear y cambiamos el tipo de ¨ªtem a "SNMPv* agent", con la versi¨®n que corresponda. Ingresamos la community (usualmente public) y el valor textual o num¨¦rico del OID que obtuvimos antes, por ejemplo: .1.3.6.1.2.1.2.2.1.10.3
Ingrese el puerto SNMP, por defecto 161, y en el campo key algo con sentido como SNMP-InOctets-Bps. El tipo de informaci¨®n debe ser cambiado a Numeric (float) y en preprocessing un paso con Change per second o Simple Change dependiendo de lo que se quiera representar, dado que es un contador y siempre va creciendo. Otro paso con un custom multiplier si se desea para convertir a Bytes. En los campos 'Update interval' y 'History storage period' ingrese los valores en que se desea actualizar y durante cuanto tiempo se va a mantener esta informaci¨®n.
Todos los campos obligatorios est¨¢n marcados con asterisco rojo
Guarde los cambios haciendo click en el bot¨®n Add y vaya a Monitoring ¡ú Latest data para ver los datos cosechados.
N¨®tese las opciones esec¨ªficas para SNMPv3:
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç | ¶Ù±ð²õ³¦°ù¾±±è³¦¾±¨®²Ô |
|---|---|
| Context name | Ingrese el context name para identificar al item en la subnet SNMP. Context name se soporta desde Áú»¢¶Ä²© 2.2. Pueden usarse User macros en este campo. |
| Security name | Ingrese el security name. Se pueden usar User macros en este campo. |
| Security level | Seleccione el nivel de seguridad: noAuthNoPriv - no se utiliza autenticaci¨®n ni protocolos de privacidad AuthNoPriv - se utiliza el protocolo de autenticaci¨®n no el protocolo de privacidad AuthPriv - se utilizan ambos protocolos |
| Authentication protocol | Seleccione el protocolo de autenticaci¨®n - MD5 or SHA. |
| Authentication passphrase | Ingrese la authentication passphrase. Pueden usarse User macros en este campo. |
| Privacy protocol | Seleccione el protocolo de privacidad - DES or AES. |
| Privacy passphrase | Ingrese la privacy passphrase. Pueden usarse User macros en este campo. |
En caso de credenciales SNMPv3 incorrectas (security name, authentication protocol/passphrase, privacy protocol), Áú»¢¶Ä²© recibe un ERROR del net'snmp, excepto por Privacy passphrase incorrectasm en cuyo caso Áú»¢¶Ä²© recibe un error de TIMEOUT de net-snmp.
Se requiere un reinicio en el Server/proxy para que los cambios en Authentication protocol, Authentication passphrase, Privacy protocol o Privacy passphrase tengan efecto.
Ejemplo 1
Ejemplo general?
| ±Ê²¹°ù¨¢³¾±ð³Ù°ù´Ç | ¶Ù±ð²õ³¦°ù¾±³¦¾±¨®²Ô |
|---|---|
| Community | public |
| OID | 1.2.3.45.6.7.8.0 (or .1.2.3.45.6.7.8.0) |
| Key | <String ¨²nico para referenciar el ¨ªtem en los triggers> Por ejemplo, "my_param". |
Note that OID can be given in either numeric or string form. However, in some cases, string OID must be converted to numeric representation. Utility snmpget may be used for this purpose:
Monitoring of SNMP parameters is possible if --with-net-snmp flag was specified while configuring Áú»¢¶Ä²© sources.
Example 2
Monitoring of uptime:
| Parameter | Description |
|---|---|
| Community | public |
| Oid | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | Float |
| Units | uptime |
| Multiplier | 0.01 |
Internal workings of bulk processing
Starting from 2.2.3 Áú»¢¶Ä²© server and proxy query SNMP devices for multiple values in a single request. This affects several types of SNMP items:
- regular SNMP items;
- SNMP items with dynamic indexes;
- SNMP low-level discovery rules.
All SNMP items on a single interface with identical parameters are scheduled to be queried at the same time. The first two types of items are taken by pollers in batches of at most 128 items, whereas low-level discovery rules are processed individually, as before.
On the lower level, there are two kinds of operations performed for querying values: getting multiple specified objects and walking an OID tree.
For "getting", a GetRequest-PDU is used with at most 128 variable bindings. For "walking", a GetNextRequest-PDU is used for SNMPv1 and GetBulkRequest with "max-repetitions" field of at most 128 is used for SNMPv2 and SNMPv3.
Thus, the benefits of bulk processing for each SNMP item type are outlined below:
- regular SNMP items benefit from "getting" improvements;
- SNMP items with dynamic indexes benefit from both "getting" and "walking" improvements: "getting" is used for index verification and "walking" for building the cache;
- SNMP low-level discovery rules benefit from "walking" improvements.
However, there is a technical issue that not all devices are capable of returning 128 values per request. Some always return a proper response, but others either respond with a "tooBig(1)" error or do not respond at all once the potential response is over a certain limit.
In order to find an optimal number of objects to query for a given device, Áú»¢¶Ä²© uses the following strategy. It starts cautiously with querying 1 value in a request. If that is successful, it queries 2 values in a request. If that is successful again, it queries 3 values in a request and continues similarly by multiplying the number of queried objects by 1.5, resulting in the following sequence of request sizes: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
However, once a device refuses to give a proper response (for example, for 42 variables), Áú»¢¶Ä²© does two things.
First, for the current item batch it halves the number of objects in a single request and queries 21 variables. If the device is alive, then the query should work in the vast majority of cases, because 28 variables were known to work and 21 is significantly less than that. However, if that still fails, then Áú»¢¶Ä²© falls back to querying values one by one. If it still fails at this point, then the device is definitely not responding and request size is not an issue.
The second thing Áú»¢¶Ä²© does for subsequent item batches is it starts with the last successful number of variables (28 in our example) and continues incrementing request sizes by 1 until the limit is hit. For example, assuming the largest response size is 32 variables, the subsequent requests will be of sizes 29, 30, 31, 32, and 33. The last request will fail and Áú»¢¶Ä²© will never issue a request of size 33 again. From that point on, Áú»¢¶Ä²© will query at most 32 variables for this device.
If large queries fail with this number of variables, it can mean one of two things. The exact criteria that a device uses for limiting response size cannot be known, but we try to approximate that using the number of variables. So the first possibility is that this number of variables is around the device's actual response size limit in the general case: sometimes response is less than the limit, sometimes it is greater than that. The second possibility is that a UDP packet in either direction simply got lost. For these reasons, if Áú»¢¶Ä²© gets a failed query, it reduces the maximum number of variables to try to get deeper into the device's comfortable range, but (starting from 2.2.8) only up to two times.
In the example above, if a query with 32 variables happens to fail, Áú»¢¶Ä²© will reduce the count to 31. If that happens to fail, too, Áú»¢¶Ä²© will reduce the count to 30. However, Áú»¢¶Ä²© will not reduce the count below 30, because it will assume that further failures are due to UDP packets getting lost, rather than the device's limit.
If, however, a device cannot handle bulk requests properly for other reasons and the heuristic described above does not work, since Áú»¢¶Ä²© 2.4 there is a "Use bulk requests" setting for each interface that allows to disable bulk requests for that device.