Monitorización vía SNMP

Los routers, switches, firewalls, impresoras, appliances, SAI, sensores de hardware y muchos otros dispositivos no permiten la instalación de un agente Checkmk. Sin embargo, ya cuentan con una interfaz integrada de monitorización proporcionada por su fabricante: un agente SNMP. Se puede acceder a este agente a través del Protocolo simple de gestión de redes (SNMP). Checkmk utiliza SNMP para monitorizar este tipo de dispositivos. La ventaja para ti es que configurar la monitorización es muy fácil.

También hay agentes SNMP para Windows y Linux, pero no se recomienda usarlos en lugar del agente Checkmk. El SNMP no es muy eficiente, por lo que utilizarlo para la monitorización suele significar que el servidor Checkmk necesita más CPU y memoria por host que cuando se trabaja con su propio agente. Además, los datos proporcionados a través de SNMP son incompletos. En algunos casos, sin embargo, la monitorización a través de SNMP además del agente Checkmk puede resultar útil. Consulta el capítulo sobre SNMP y el agente Checkmk para obtener más información sobre este tema.

No obstante, si no hay ningún plugin de agente Checkmk para supervisar un componente de hardware o software concreto (por ejemplo, un controlador RAID), pero el componente tiene una interfaz SNMP, por supuesto puedes recopilar datos de monitorización adicionales a través de SNMP. En tal caso, asegúrate de que los intervalos de consulta sean lo suficientemente largos.

Monitorizar dispositivos SNMP con Checkmk es muy fácil. Si solo quieres empezar rápidamente con SNMP, probablemente tendrás que leer la breve sección sobre SNMP en la Guía para principiantes. Este artículo, por otro lado, profundiza mucho más y te muestra todos los detalles y escenarios específicos de la monitorización SNMP con Checkmk.

El protocolo SNMP está disponible en diferentes versiones. Estos protocolos son incompatibles entre sí, por lo que el sistema de monitorización y el dispositivo monitorizado deben utilizar siempre la misma versión del protocolo. Checkmk es compatible con las versiones v1, v2c y v3. En la práctica, se estima que el 99 % de las instalaciones utilizan la v2c. Aquí tienes una vista general de todas las versiones relevantes de SNMP:

Checkmk utiliza solicitudes activas para la monitorización SNMP: un método pull. Checkmk envía un paquete UDP (puerto 161) que contiene una solicitud SNMP al dispositivo solicitando el suministro de datos específicos. A continuación, el dispositivo responde con un paquete UDP que contiene la respuesta (o un mensaje de error).

SNMP tiene un segundo proceso: las Traps SNMP. Se trata de mensajes push espontáneos enviados por los dispositivos a direcciones configuradas a través de UDP (puerto 162) en modo push. Las trampas tienen muchas desventajas respecto a las solicitudes activas, por lo que no son muy importantes para la monitorización. Algunas de las desventajas son:

Sin embargo, si quieres o necesitas trabajar con traps, la Consola de eventos ofrece una solución. Esta puede recibir traps y generar eventos a partir de ellos.

El primer paso es preparar el dispositivo. Cada dispositivo SNMP tiene su propia máscara de configuración en algún lugar de su configuración. Realiza los siguientes ajustes en esta máscara de configuración:

La comunidad es una especie de contraseña, salvo que en SNMP no hay nombre de usuario. Existe la convención de que la comunidad sea public. Este es el valor predeterminado para muchos dispositivos, y también para Checkmk. Por supuesto, puedes argumentar que esto es inseguro y que deberías especificar otra comunidad. Esto sin duda tiene sentido, pero debes saber que SNMP transmite la comunidad en texto sin cifrar (con excepción de la versión 3 de SNMP). Cualquiera que pueda interceptar los paquetes puede, por lo tanto, identificar muy fácilmente la comunidad. Por otro lado, el acceso está limitado a solo lectura, y la mayor parte de la información que se puede obtener a través de SNMP no es muy crítica.

Además, el uso de comunidades diferentes por dispositivo resulta muy engorroso de manejar. Al fin y al cabo, estas no solo deben mantenerse en los dispositivos, sino también en el sistema de monitorización. Por eso, en la práctica, los usuarios suelen utilizar la misma comunidad en todas partes —o al menos en todas partes dentro de una región, departamento, centro de datos, etc.

Si quieres aumentar la seguridad incluso sin SNMP versión 3, tiene sentido ampliar el concepto de red para colocar el tráfico de los servicios de gestión, y por lo tanto también el SNMP, en una VLAN de gestión separada y proteger ese acceso con el cortafuegos.

Añade los dispositivos supervisados como hosts en Checkmk de la forma habitual. Si has elegido tu estructura de carpetas de manera que solo una carpeta contenga dispositivos SNMP, puedes realizar los demás ajustes directamente en esa carpeta. Esto facilita añadir hosts adicionales más adelante y también evita errores.

Ahora, en las propiedades del host (o carpeta), en la caja «Monitoring agents», configura «Checkmk agent / API integrations» en «No API integrations, no Checkmk agent».

En la misma caja, activa también «SNMP» y, como protocolo SNMP, selecciona «SNMPv2 or v3». La selección de la versión 1 del protocolo es una solución provisional solo para dispositivos muy antiguos. Solo debes usarla si sabes que la v2 realmente no es compatible, o cuando la implementación del dispositivo es defectuosa (en la práctica, solo en casos aislados). Sobre todo, la versión 1 de SNMP es muy lenta porque no admite accesos masivos. Esta diferencia es muy significativa.

La tercera y última configuración se llama «SNMP credentials». Aquí también hay que elegir la versión del protocolo, ya que v2c y v3 difieren en este aspecto. Hablaremos de la versión 3 más adelante. Si no tienes requisitos de seguridad muy altos, te bastará con v2c, o bien puedes colocar la comunicación SNMP en una VLAN de gestión y así protegerla. SNMPv2c requiere introducir la comunidad, tal y como se ha comentado anteriormente.

Existe una forma alternativa de configurar las credenciales SNMP, si no puedes pasarlas fácilmente a través de tu estructura de carpetas: el conjunto de reglas «Setup > Agents > SNMP rules > SNMP credentials of monitored hosts». Esto te permitirá asignar las credenciales basándote en tags del host, etiquetas y propiedades similares. El principio es que una comunidad que se establece directamente en el host o en la carpeta siempre tiene prioridad sobre las reglas.

Cuando hayas terminado con la configuración, puedes hacer un pequeño desvío por la página de diagnóstico. Para ello, guarda con el botón de la barra de acciones «Save & go to connection test».

Aquí tienes un ejemplo de los diagnósticos para un switch. Se prueban simultáneamente varias versiones del protocolo SNMP, a saber:

Un dispositivo moderno y normal debería responder a las cuatro variantes con los mismos datos, aunque esto puede verse limitado dependiendo de la configuración. El resultado tendrá este aspecto:

Aquí se describen las cuatro salidas de información:

De hecho, parece que cualquier error imaginable que se pueda cometer teóricamente al implementar SNMP ya lo ha cometido algún fabricante en algún momento. Por eso hay dispositivos en los que SNMP funciona bastante bien, pero ciertas partes del protocolo no funcionan o se han implementado incorrectamente.

Si los problemas se producen con las ediciones comerciales, una de las razones puede ser que la implementación de Inline-SNMP, que ofrece un mejor rendimiento y viene activada por defecto, depende en mayor medida del cumplimiento de los estándares que snmpget. Si los dispositivos no responden en absoluto o no lo hacen de forma fiable, a veces ayuda desactivar Inline-SNMP para los dispositivos afectados y activar así el snmpget, algo más robusto pero significativamente más lento.

Para las pruebas en la línea de comandos, el comando cmk tiene, para algunas opciones, la opción adicional --snmp-backend, que acepta inline (uso de Inline-SNMP), classic (uso de snmpget) o stored-walk (uso de un recorrido SNMP almacenado) como parámetros. Si la prueba en la línea de comandos ha tenido éxito, puedes usar el conjunto de reglas Hosts not using inline SNMP para especificar los hosts que no deben usar Inline-SNMP de forma permanente.

Has incluido un dispositivo SNMP en la monitorización, pero Checkmk solo reconoce los servicios SNMP Info y SNMP Uptime, así como las interfaces. Esto puede deberse a varias causas:

Si el ping funciona, pero ninguna de las versiones del protocolo SNMP funciona, puede haber varias causas posibles:

Por defecto, SNMP no está cifrado y, por lo tanto, la autenticación es muy débil, ya que se transmite como texto sin formato a través de la red. Este nivel puede seguir siendo suficiente para una red local y aislada, ya que en este caso la monitorización se limita a operaciones de solo lectura.

Si aún así quieres un mayor nivel de seguridad, necesitarás la versión 3 de SNMP. Esta ofrece la opción de cifrado y autenticación genuina. Para ello, sin embargo, también es necesaria una configuración adecuada.

SNMPv3 reconoce varios niveles de seguridad:

La configuración necesaria en Checkmk se realiza en el mismo lugar donde también definiste la comunidad, ya sea en las propiedades del host o en la regla de SNMP credentials of monitored hosts. Allí, en lugar de SNMP Community, selecciona uno de los tres niveles de v3 y configura los valores necesarios:

SNMPv3 introduce el concepto de contextos. Un dispositivo SNMP puede mostrar información diferente en un mismo punto del árbol SNMP, dependiendo del ID de contexto que se indique en la consulta.

Si tienes un dispositivo que funciona con estos contextos, necesitarás dos ajustes en Checkmk:

Por suerte, hay muy pocas situaciones en las que tengas que trabajar con contextos, ya que, lamentablemente, la monitorización no puede reconocerlos automáticamente. Siempre es necesaria una configuración manual de los contextos.

El rendimiento siempre es importante, sobre todo en entornos con muchos hosts, y la monitorización con SNMP consume más CPU y memoria que con los agentes Checkmk.

Mientras que Checkmk Community realiza las solicitudes SNMP de la forma clásica mediante los comandos snmpget o snmpbulkwalk, las ediciones comerciales cuentan con un motor SNMP integrado que ejecuta las solicitudes SNMP de forma muy eficiente sin generar procesos adicionales. Con esto, la carga de CPU para el procesamiento SNMP se reduce aproximadamente a la mitad. Los tiempos de sondeo más cortos también reducen el número de procesos de Checkmk necesarios simultáneamente y, por lo tanto, la carga de memoria.

Si tus recursos llegan al límite, o si se tarda más de 60 segundos en sondear un solo dispositivo, puedes reducir el intervalo con el que Checkmk consulta al host o hosts. Con el conjunto de reglas «Normal check interval for service checks», que se aplica específicamente a los servicios de Checkmk de los hosts, puedes ampliar el intervalo general de un minuto a, por ejemplo, 2 o 5 minutos.

Especialmente para las comprobaciones SNMP, también existe el conjunto de reglas «Fetch intervals for SNMP sections». Esto te permite reducir el intervalo para check plugins individuales. Es importante saber que nunca puedes establecer un intervalo más rápido que el intervalo de monitorización general del servicio «Check_MK».

En general, sin embargo, recomendamos que la monitorización se diseñe de manera que se pueda mantener el intervalo estándar de un minuto, y que solo se aumente en casos de excepción para hosts o checks individuales.

Por defecto, Checkmk espera una respuesta en menos de un segundo para una solicitud SNMP. Además, lo intenta un total de tres veces antes de darse por vencido. Para dispositivos que responden muy lentamente, o a los que solo se puede acceder a través de una red muy lenta, puede ser necesario cambiar estos parámetros. Esto se hace a través del conjunto de reglas «Timing settings for SNMP access»:

Ten en cuenta que estos ajustes se aplican a una solicitud SNMP individual. El proceso completo de monitorización de un host consta de muchas solicitudes independientes. Por lo tanto, el timeout total es un múltiplo de los ajustes especificados aquí.

Por defecto, SNMP transmite 10 respuestas en un paquete por cada solicitud «GetBulk». Prueba el conjunto de reglas «Bulk walk: Number of OIDs per bulk» para ver si un valor más alto funciona mejor. Sin embargo, esto solo ocurrirá cuando se transfieran tablas grandes al host, por ejemplo, si se trata de un switch con muchos puertos.

SNMP siempre llena los paquetes hasta el número especificado, incluyendo cualquier registro que siga a los realmente necesarios. Y si solo se necesitan unos pocos de estos registros, se transfieren datos adicionales innecesarios y aumenta la sobrecarga.

Por otro lado, en la práctica puede ocurrir ocasionalmente que los dispositivos con el valor por defecto de 10 OID por bloque puedan tener problemas. En tal caso, puede ser útil reducir el número.

Checkmk suele funcionar obteniendo siempre la información de todos los puertos del switch, aunque no todos estén siendo monitorizados realmente. Esto es bueno de todos modos, ya que normalmente es más rápido porque no se pueden realizar consultas individuales con las eficientes solicitudes masivas. Además, desde nuestro punto de vista, siempre es recomendable realizar la monitorización de todos los puertos para detectar puertos defectuosos o cables con altas tasas de error. Si los puertos no son fiables UP, también puedes marcar el estado del enlace DOWN como OK.

Sin embargo, hay casos aislados en los que los switches tienen muchísimos puertos y, por alguna razón, responden muy lentamente o realizan el proceso de SNMP de forma muy ineficiente, por lo que ya no es posible realizar la monitorización con una recuperación completa de toda la información de los puertos.

Para estos casos, existe el conjunto de reglas «Bulk walk: Limit SNMP OID Ranges». Esto te permite limitar de forma estática la lista de datos consultados (por ejemplo, los puertos). En el valor de la regla, para cada check plugin concreto, especificas qué índices de la tabla correspondiente se deben recuperar.

El tipo de check habitual para los puertos del switch se llama «SNMP interface check with 64 bit counters (using v2c)». El siguiente ejemplo muestra una configuración en la que solo se recuperan los dos primeros puertos a través de SNMP:

Nota: Este filtrado se aplica antes del descubrimiento de servicios y la monitorización del servicio. Dependiendo de la configuración de «Network interface and switch port discovery», esto no significa automáticamente que estos dos puertos vayan a ser supervisados.

El motor SNMP de Checkmk tiene una función muy útil: puedes hacer que un dispositivo supervisado escriba una instantánea completa de todos sus datos SNMP en un archivo, un recorrido SNMP. Puedes usar este archivo más tarde para simular la monitorización del dispositivo en otro servidor Checkmk, incluso si este otro servidor no tiene conexión de red real con el dispositivo.

Usamos esta función mucho, por ejemplo, cuando nuestro equipo de soporte está desarrollando nuevos check plugins para nuestros clientes. Por eso, nuestros desarrolladores no necesitan acceso a tus dispositivos, solo un recorrido SNMP.

Puedes crear un recorrido SNMP directamente desde la GUI. La función se encuentra en el menú de acciones del servicio «Check_MK» de los hosts y también en el menú de acciones de los hosts (entrada «Download SNMP walk»):

La creación del walk tarda unos segundos en el mejor de los casos, pero no es raro que tarde unos minutos. Cuando la compilación haya terminado, puedes descargar el archivo creado a través de la línea «Result».

Como alternativa, también puedes crear recorridos desde la línea de comandos. Inicia sesión en el site desde el que se supervisa el dispositivo. La creación del recorrido se realiza simplemente con el comando cmk --snmpwalk y el host especificado (que debe estar configurado en la monitorización):

Utiliza también el switch `-v` para ver información más detallada sobre el progreso:

El archivo se guardará en el directorio var/check_mk/snmpwalks, donde simplemente llevará el nombre del host. Es un archivo de texto. Si tienes curiosidad, puedes verlo, por ejemplo, con less; sal del programa con la tecla Q:

El comando cmk --snmpwalk tiene algunas opciones más útiles:

Si quieres usar este recorrido en un site de Checkmk diferente (o en el mismo) para una simulación, guarda el archivo del recorrido con el nombre del host de este site en var/check_mk/snmpwalks. Asegúrate de que el usuario del site sea el propietario del archivo y de que los permisos estén configurados como «0600» (solo el propietario puede leer y escribir).

Ahora crea una regla en el conjunto de reglas Simulating SNMP by using a stored SNMP walk que acceda a los hosts afectados.

A partir de ahora, solo se utilizará el archivo guardado para la monitorización del host. Ahora no hay acceso de red al host, excepto el ping para la comprobación del host y, posiblemente, cualquier comprobación activa configurada. Puedes redirigirlas simplemente al servidor Checkmk asignando la dirección IP 127.0.0.1 a los hosts.