 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. ¿Qué es SNMP?
1.1. Utilizar SNMP en lugar de un agente Checkmk
Los routers, conmutadores, cortafuegos, impresoras, electrodomésticos, SAI, sensores de hardware y muchos otros dispositivos no permiten la instalación de un agente Checkmk. Sin embargo, ya tienen una interfaz integrada para la monitorización proporcionada por su fabricante: un agente SNMP. Se puede acceder a este agente mediante el Protocolo simple de gestión de redes (SNMP). Checkmk utiliza SNMP para monitorizar estos 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 utilizarlos en lugar del agente Checkmk. SNMP no tiene un gran rendimiento, por lo que utilizarlo para la monitorización suele significar que el servidor Checkmk necesita más CPU y memoria por host que cuando trabaja con su propio agente. Además, los datos proporcionados a través de SNMP son incompletos. En algunos casos, sin embargo, puede ser útil la monitorización a través de SNMP además del agente Checkmk. Para más información sobre este tema, consulta el capítulo sobre SNMP y el agente Checkmk.
Sin embargo, si no existe un Plugin de agente Checkmk para monitorizar un determinado componente de hardware o software (por ejemplo, un controlador RAID), pero el componente tiene una interfaz SNMP, puedes, por supuesto, recopilar datos de monitorización adicionales mediante SNMP. En tal caso, asegúrate de que los intervalos de consulta son lo suficientemente largos.
La monitorización de dispositivos SNMP con Checkmk es muy fácil. Si sólo quieres empezar rápidamente con SNMP, probablemente necesites leer la breve sección sobre SNMP de la guía para principiantes. Este artículo profundiza mucho más y te muestra todos los detalles y escenarios específicos de la monitorización SNMP con Checkmk.
1.2. Versiones SNMP
El protocolo SNMP está disponible en diferentes versiones. Todos 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 admite las versiones v1, v2c y v3. En la práctica, se calcula que el 99 % de las instalaciones utilizan la v2c. A continuación te ofrecemos una vista general de todas las versiones relevantes de SNMP:
| Versión | Características | Checkmk | Descripción y aplicación en la práctica |
|---|---|---|---|
v1 |
sí |
Utilizar sólo en dispositivos muy antiguos (digamos, de 15 años o más) que no sean compatibles con v2c, o su compatibilidad con v2c sea defectuosa. |
|
v2c |
Consultas masivas, |
sí |
Ésta es la norma en la práctica. v2c es una variante "ligera" de v2 y la "c" aquí significa Community, que desempeña el papel de una contraseña en SNMP. Los contadores de 64 bits son esenciales en la monitorización de puertos del switch de 1 Gbit/s y más. Las consultas masivas aceleran la monitorización hasta un factor de 10. |
v2 |
Seguridad |
sin |
La versión 2 ofrece opciones de seguridad aún mejores, además de las funciones de la v2c. La versión 2 de SNMP no se encuentra en la práctica, por lo que CMK no admite esta versión del protocolo. Si necesitas seguridad, utiliza en su lugar la versión 3. |
v3 |
Seguridad, |
sí |
La versión 3 se utiliza para encriptar el tráfico SNMP. Con v2c y v1 se ejecuta en texto plano, incluso en la comunidad. En la práctica, la versión 3 es bastante menos habitual, porque esta versión requiere bastante más potencia de cálculo, y además el coste de la configuración es significativamente mayor que con v2c. Los Contextos son un concepto en el que es visible información diferente en la misma zona de la estructura de datos SNMP (OID), dependiendo del ID del contexto. Esto se utilizaría, por ejemplo, para la partición de conmutadores de canal de fibra. |
1.3. Traps SNMP
Checkmk utiliza peticiones activas para la monitorización SNMP: un método pull. Checkmk envía un paquete UDP (puerto 161) que contiene una petición SNMP al dispositivo solicitando el suministro de datos específicos. A continuación, el dispositivo responde con un paquete UDP que contiene los datos de respuesta (o un mensaje de error).
SNMP tiene un segundo proceso: Los Traps SNMP. Son mensajes push espontáneos que envían los dispositivos a direcciones configuradas a través de UDP (puerto 162) en modo push. Los Traps tienen muchas desventajas respecto a las peticiones activas, razón por la que no son muy importantes para la monitorización. Algunas de las desventajas son:
Las trampas no son fiables. Los paquetes UDP pueden perderse. No hay confirmación de recepción.
En la mayoría de los casos sólo se envían mensajes de Error, pero no mensajes de Recuperación. Por tanto, el estado actual de la monitorización no está claro.
Si miles de conmutadores envían traps simultáneamente (por ejemplo, si un servicio importante de subida no está disponible para ellos), el receptor de traps no podrá gestionarlo y se romperá bajo la carga. La monitorización se sobrecargará cuando más la necesites.
Al cambiar la dirección IP del receptor de trampas, hay que reconfigurar todos los dispositivos.
Las trampas son difíciles de probar. Pocos dispositivos tienen siquiera una función para enviar una trampa de prueba genérica, por no hablar de probar mensajes de error reales. Por tanto, es difícil predecir si una trampa importante se procesará correctamente cuando se produzca su primera invocación al cabo de unos meses o años.
Sin embargo, si quieres o necesitas trabajar con trampas, la Consola de eventos te ofrece una solución. Ésta puede recibir trampas y generar eventos a partir de ellas.
2. Configuración de SNMP en Checkmk
2.1. Preparar un dispositivo
El primer paso es preparar el dispositivo. Cada dispositivo que soporta 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:
Ir a configuración para consultas activas (SNMP GET). (No confundas esto con los traps - la terminología en los diálogos de configuración puede ser muy confusa).
Habilita SNMP para peticiones de lectura.
Introduce las direcciones de tus servidores Checkmk como direcciones IP permitidas. También puede ser útil proporcionar aquí un sitio Checkmk de prueba. Importante: Si tienes varios servidores Checkmk redundantes, no olvides especificar también la(s) dirección(es) IP utilizada(s) tras un Failover. En el caso del appliance Checkmk en particular, éste utiliza la dirección IP del nodo activo como dirección IP de origen para las conexiones salientes, y no la dirección IP de servicio. En un entorno de monitorización distribuida, la dirección IP del site remoto desde el que se monitoriza el dispositivo es fundamental.
Asigna una Comunidad si se van a utilizar las versiones v1 y v2c del protocolo.
La Comunidad es una especie de contraseña, salvo que no hay nombre de usuario para SNMP. Existe la convención de que la comunidad es public. Éste es el valor por defecto para muchos dispositivos -y también para Checkmk. Por supuesto, puedes argumentar que esto es inseguro y que deberías especificar otra comunidad.
Ciertamente, esto tiene sentido, pero debes saber que SNMP transmite la comunidad en texto plano (excepto para SNMP Versión 3).Por tanto, cualquiera que pueda escuchar los paquetes puede identificar muy fácilmente la comunidad. Por otra parte, tienes acceso limitado a sólo lectura, y la mayor parte de la información que se puede recuperar mediante SNMP no es muy crítica.
Además, el uso de diferentes comunidades por dispositivo es muy engorroso de manejar. Al fin y al cabo, no sólo hay que mantenerlas 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.
Consejo: Si quieres aumentar la seguridad incluso sin SNMP versión 3, tiene sentido ampliar el concepto de red de modo que coloques el tráfico con los servicios de gestión, y por tanto también SNMP, en una VLAN de gestión separada y asegures ese acceso con el cortafuegos.
2.2. Añadir un dispositivo a Checkmk
Añade los dispositivos monitorizados como hosts en Checkmk de la forma habitual. Si has elegido tu estructura de carpetas de forma que sólo una carpeta contenga dispositivos SNMP, puedes realizar el resto de 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 establece Checkmk agent / API integrations en No API integrations, no Checkmk agent.
En la misma caja, activa también SNMP y como protocolo SNMP selecciona SNMP v2 or v3. La selección de la versión 1 del protocolo es una solución improvisada sólo para dispositivos muy antiguos. Sólo debes utilizarla si sabes que la versión 2 realmente no es compatible, o cuando la implementación para el dispositivo es defectuosa (en la práctica, sólo 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 denomina SNMP credentials. Aquí también es necesario elegir la versión del protocolo, ya que aquí difieren v2c y v3. Más adelante hablaremos de la versión 3. Si no tienes requisitos de seguridad muy elevados, te servirá bien v2c -o puedes colocar la comunicación SNMP en una VLAN de gestión y así asegurarla-. SNMP v2c requiere la introducción de la Comunidad, como ya se ha comentado.
Hay una forma alternativa de configurar las credenciales SNMP, si no puedes hacerlo 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 carpeta siempre tiene prioridad sobre las reglas.
Monitorización mediante SNMP y agente Checkmk
De vez en cuando surge la pregunta de si no sería posible o incluso útil monitorizar Linux o Windows utilizando SNMP en lugar del agente Checkmk. La respuesta es muy sencilla: posible sí, útil no. ¿Por qué?
Los datos de monitorización del agente SNMP son muy limitados. Por tanto, necesitas el agente Checkmk para una monitorización medianamente útil.
El agente SNMP no proporciona ningún dato significativo que no proporcionaría el agente Checkmk.
El agente SNMP es más engorroso de configurar.
Por último, pero no por ello menos importante, el protocolo SNMP requiere muchos más recursos de CPU y de red que la monitorización normal con Checkmk.
Sin embargo, hay algunas situaciones en las que puede ser útil la monitorización mediante SNMP, además del agente Checkmk, lo que puede implicar tanto al agente Checkmk para Linux como para Windows. Un ejemplo típico es que para un componente de software o hardware (por ejemplo, un controlador RAID) se instale una herramienta del fabricante del servidor que proporcione datos de monitorización sólo mediante SNMP, como ocurre con Fujitsu ServerView, por ejemplo. Entonces, por supuesto, puedes recopilar datos de monitorización adicionales mediante SNMP. En este caso, asegúrate de que los intervalos de consulta son suficientemente largos. Con Windows también puede ocurrir que no sea posible realizar una consulta mediante PowerShell, debido a la versión de Windows utilizada o a que no existen Cmdlets para la aplicación.
En tal caso, si quieres supervisar el host Linux o Windows mediante el agente Checkmk y SNMP, haz lo siguiente: en las propiedades del host, en el menú Setup, en la caja Monitoring agents, establece la opción Checkmk agent / API integrations en un valor con agente Checkmk (API integrations if configured, else Checkmk agent o Configured API integrations and Checkmk agent). En la misma caja, activa la opción SNMP y establece el valor SNMP v2 or v3 o SNMP v1, como se ha descrito anteriormente:
Los servicios que están disponibles tanto a través de SNMP como del agente Checkmk (por ejemplo, carga de CPU, sistemas de archivos, tarjetas de red) se obtienen automáticamente del agente Checkmk y no a través de SNMP.
2.3. Diagnóstico
Cuando hayas terminado con los ajustes, puedes dar un pequeño rodeo a través de la página de diagnósticos. Para ello, guarda con el botón de la barra de acciones Save & go to connection test. Aquí tienes un ejemplo del diagnóstico de un conmutador. Se prueban simultáneamente varias versiones de protocolo de SNMP, a saber:
SNMP v1
SNMP v2c
SNMP v2c sin consultas masivas
SNMP v3
Un aparato normal y moderno debería responder a las cuatro variantes con los mismos datos, aunque esto puede verse limitado en función de la configuración. El resultado tendrá el siguiente aspecto:
Aquí se describen las cuatro salidas de información:
|
La descripción del aparato tal y como está codificada en el firmware del aparato por el fabricante. Este texto es muy importante para Checkmk para el descubrimiento automático de servicios. |
|
Este campo sirve para especificar una persona de contacto y lo defines tú en la configuración del dispositivo. |
|
Aquí se indica el nombre del host del dispositivo. Este campo también se configura en el dispositivo. Para la monitorización real, el nombre no desempeña ningún otro papel y sólo se muestra a título informativo. Sin embargo, tiene sentido y es útil si el nombre del host aquí coincide con el nombre del host en Checkmk. |
|
Este es un campo para una entrada de texto libre -sólo a título informativo- en el que puedes introducir la ubicación del dispositivo. |
2.4. La configuración del servicio
Características especiales de los dispositivos SNMP
Después de guardar las propiedades del host (y opcionalmente los diagnósticos), el siguiente paso suele ser la configuración de los servicios. Esto tiene algunas peculiaridades, porque internamente el descubrimiento de servicios se hace de forma muy diferente en los dispositivos SNMP en comparación con los host, que se monitorizan con el agente Checkmk. Checkmk puede simplemente mirar la salida del agente y encontrar los items de interés utilizando los check plugins individuales. Con SNMP hay que trabajar un poco más. Aunque Checkmk podría realizar una detección y generar una salida completa de todos los datos SNMP (SNMP walk), y en ella buscar información interesante, ¡pero hay dispositivos para los que una sola detección llevaría varias horas!
Sin embargo, Checkmk tiene un enfoque más inteligente. Inicialmente, sólo recupera los dos primeros registros (OID) del dispositivo: el sysDescr y el sysObjectID. A partir de ahí, según sea necesario, se invocan más consultas. Basándose en los resultados, cada uno de los casi 1 000 check plugins SNMP suministrados decide si el dispositivo admite realmente este check plugin. Checkmk llama a esta fase la exploración SNMP, y como resultado el software produce una lista de check plugins que sirven como candidatos para el descubrimiento de servicios real.
En un segundo paso se ejecuta la detección propiamente dicha. Los Plugin encontrados recuperan los datos exactos que necesitan mediante consultas SNMP locales, y utilizan estos datos para determinar los servicios que hay que monitorizar. Los datos recuperados son precisamente los que más tarde se obtendrán regularmente para la monitorización.
Para los dispositivos de una LAN, todo el proceso no suele llevar mucho tiempo -más de varios segundos sería una excepción-. Sin embargo, si monitorizas dispositivos a través de enlaces WAN de alta latencia, el escaneo completo puede llevar varios minutos. Por supuesto, un escaneo también lleva más tiempo para los conmutadores con cientos de puertos. Ahora bien, sería muy poco práctico si tuvieras que esperar tanto tiempo cada vez que abres la página de los servicios.
Por eso, la Configuración normalmente se salta el escaneo, y sólo hace la detección con los check plugins que ya están en uso en el host. Entonces, los paseos SNMP ya están disponibles como archivos de caché a través de la monitorización normal, y la detección no tarda mucho. Con esto podrás encontrar nuevos items de los check plugins existentes (por ejemplo, nuevos puertos del switch, discos duros, sensores, VPNs, etc.), pero no encontrar plugins totalmente nuevos.
El botón Full service scan fuerza una búsqueda SNMP y obtiene datos nuevos a través de SNMP. Como resultado, también se encuentran servicios de Plugins completamente nuevos. Puede ser necesario esperar a que los dispositivos respondan con lentitud.
Servicios estándar
Independientemente del dispositivo que monitorices mediante SNMP, en la configuración deben aparecer, como mínimo, los tres servicios siguientes:
El primer servicio es un check que monitoriza los puertos de red. Al menos uno debe tener el dispositivo y estar activo; de lo contrario, SNMP no funcionaría. En general, Checkmk está preconfigurado para que incluya en la monitorización todos los puertos que estén activos en el momento de un descubrimiento de servicios (estado operativo "up"). Puedes influir en esto con el conjunto de reglas Setup > Services > Service discovery rules > Network interface and switch port discovery.
Por cierto, en la guía para principiantes encontrarás un capítulo sobre las mejores prácticas a la hora de configurar los puertos del switch.
El segundo es el servicio SNMP Info, que muestra los mismos cuatro datos que has visto en el diagnóstico. Tiene una función puramente informal y siempre es OK.
Por último está el servicio Uptime, que te muestra cuándo se reinició el dispositivo por última vez. Este servicio siempre está OK por defecto, pero puedes establecer umbrales superiores e inferiores para el tiempo de actividad.
3. Cuando los dispositivos crean problemas
3.1. Una implementación SNMP defectuosa
En realidad, parece como si cualquier error concebible que teóricamente pueda cometerse al implementar SNMP ya lo hubiera cometido algún fabricante en algún momento. Y así, hay dispositivos con los que SNMP funciona razonablemente bien, pero ciertas partes del protocolo no, o se han implementado incorrectamente.
Si los problemas ocurren con las ediciones comerciales, una de las razones puede ser que la implementación de SNMP en línea, de mayor rendimiento y que está activada por defecto en ellas, se basa más en el 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 SNMP en línea para los dispositivos afectados y activar así la implementación algo más robusta y significativamente más lenta snmpget.
Para las pruebas en la línea de comandos, el comando cmk tiene para algunas opciones la opción adicional --snmp-backend, que acepta como parámetros inline (uso de SNMP en línea), classic (uso de snmpget) o stored-walk (uso de un paseo SNMP almacenado). Si la prueba en la línea de comandos ha tenido éxito, puedes utilizar el conjunto de reglas Hosts not using Inline-SNMP para especificar los host que no deben utilizar SNMP en línea de forma permanente.
No hay respuesta para una petición a 'sysDescr'
Un posible error se produce cuando los agentes SNMP no responden a la solicitud de información estándar: por ejemplo, no responden a sysDescr. Estos dispositivos están como muertos en un diagnóstico, y no ofrecerán ningún resultado a un descubrimiento de servicios si no les ayudas con una configuración especial.
Para ello, crea para los host afectados una regla en Setup > Agents > SNMP rules > Hosts without system description OID con la opción Positive match (Add matching hosts to the set). Checkmk asumirá entonces que todo está bien y omitirá la prueba con la opción sysDescr. Aunque no se detectarán check plugins que esperen partes específicas en este texto, en la práctica esto no importa, ya que los plugins afectados están diseñados para adaptarse a esta condición.
SNMP v2c funciona, pero las solicitudes masivas fallan
Algunos dispositivos admiten la versión v2c -y proporcionarán una respuesta al respecto en los diagnósticos-, sin embargo, en el protocolo falta la implementación del comando GetBulk. Éste es utilizado por Checkmk para obtener tanta información como sea posible con una sola petición y es muy importante para el rendimiento.
Con un host así, funcionarán algunos simples checks SNMP - como SNMP Info o SNMP Uptime, pero faltarán otros servicios - especialmente las interfaces de red que deben estar presentes en cada dispositivo.
Si realmente tienes un host en el que esto es así, puedes ejecutarlo con v2c, pero sin peticiones masivas. Configura dicho host como sigue:
Establece la versión SNMP de las propiedades del host en SNMP v1.
En el conjunto de reglas Setup > Agents > SNMP rules > Legacy SNMP devices using SNMP v2c, crea una regla para el host y establece el valor típico Positive match (Add matching hosts to the set).
Esto obliga al host a utilizar el protocolo SNMP v2c -aunque se haya establecido la versión 1-, pero sin bulkwalk. Por cierto, no recomendamos el uso de SNMP v1 -aunque sea compatible- porque no admite contadores de 64 bits, lo que puede provocar que falten datos de medición o que éstos sean erróneos en los puertos de red sometidos a mucho tráfico.
Dispositivos que responden muy lentamente
Hay algunos dispositivos con los que algunas consultas SNMP tardan mucho tiempo. Esto se debe en parte a implementaciones incorrectas. Aquí a veces puede ayudar volver a SNMP v1 -que suele ser mucho más lento, pero aún así a veces puede ser más rápido que un SNMP v2c estropeado-. Sin embargo, antes de intentarlo, debes comprobar si el fabricante proporciona una actualización de firmware que resuelva el problema.
Una segunda causa puede ser que el dispositivo tenga muchos puertos del switch, y también una implementación SNMP lenta. Si sólo quieres monitorizar unos pocos puertos (sólo los dos primeros, por ejemplo), puedes limitar manualmente Checkmk para que sondee sólo los puertos especificados. Encontrarás más detalles al respecto más adelante, en Rendimiento.
3.2. Sólo se encuentran los servicios estándar
Has incluido un dispositivo SNMP en la monitorización, pero Checkmk sólo reconoce los servicios SNMP Info y SNMP Uptime y las interfaces. Esto puede deberse a varias causas:
a) No hay Plugin
Checkmk proporciona casi 1.000 check plugins para dispositivos SNMP, pero incluso esta lista, naturalmente, nunca está completa. Una y otra vez se comprueba que para determinados dispositivos Checkmk no proporciona ningún check plugin específico, lo que significa que sólo puedes monitorizar los servicios estándar mencionados. Aquí tienes las siguientes opciones:
Puedes encontrar un Plugin adecuado en el Checkmk Exchange, donde los usuarios pueden subir sus propios Plugins.
Desarrollar tú mismo los Plugin. Encontrarás artículos en este Manual de usuario.
Ponte en contacto con nuestro equipo de soporte o con uno de nuestros socios y pídeles que desarrollen Plugins adecuados.
b) No se reconocen los Plugin
A veces ocurre que una nueva versión del firmware de un dispositivo hace que los Plugins Checkmk dejen de reconocerlo, por ejemplo, porque ha cambiado un texto en la descripción del sistema del dispositivo. En tal caso, hay que adaptar los Plugins existentes. Ponte en contacto con nuestro equipo de soporte para ello.
c) El dispositivo no proporciona los datos necesarios
Algunos (pocos) dispositivos tienen la capacidad de configurar individualmente el acceso a áreas de información específicas en su configuración SNMP. Puede que tu dispositivo esté configurado para entregar la información por defecto, pero no la de los servicios específicos del dispositivo.
En unos pocos dispositivos debes utilizar SNMP v3 y Contextos para obtener los datos que deseas.
3.3. Dispositivos que no responden en absoluto al SNMP
Si el ping funciona, pero no funciona ninguna de las versiones del protocolo SNMP, puede haber varias causas posibles:
El dispositivo no es accesible en absoluto a través de IP. Puedes comprobarlo con la Prueba Ping (primera caja).
El aparato no es compatible con SNMP.
El recurso compartido SNMP no está configurado correctamente (activación, direcciones permitidas, Community).
Un cortafuegos bloquea SNMP. Tienes que abrir el puerto UDP 161 tanto para el tráfico saliente como para el entrante.
4. SNMP v3
4.1. Seguridad
Por defecto, el SNMP no está encriptado y, por tanto, la autenticación de una Community transmitida como texto plano a través de la red es muy deficiente. Este nivel puede seguir siendo suficiente para una red local y aislada, ya que aquí la monitorización se limita al acceso a operaciones de sólo lectura.
Si aún quieres un mayor nivel de seguridad, necesitarás la versión 3 de SNMP, que ofrece la opción de encriptación y autenticación genuina, aunque para ello también es necesaria la configuración correspondiente.
SNMP v3 reconoce varios niveles de seguridad:
|
Sin autenticación real, basada en el usuario, sin encriptación. Sin embargo, la ventaja sobre v2c es que la contraseña ya no se transmite en texto plano, sino que se codifica. |
|
Autenticación basada en el usuario con un nombre (Security name) y una contraseña, pero sin encriptación. |
|
Autenticación basada en el usuario como con |
La configuración necesaria en Checkmk se realiza en el mismo lugar en el que también definiste la Comunidad: en las propiedades del host o en la regla SNMP credentials of monitored hosts. Allí, en lugar de SNMP Community, selecciona uno de los tres niveles de v3 y configura los valores necesarios:
4.2. Contextos
SNMP v3 introduce el concepto de Contextos. Un dispositivo 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 este tipo de contextos, necesitarás dos configuraciones en Checkmk:
En primer lugar, el dispositivo debe ser consultado utilizando SNMP v3 (como se describe en la sección anterior).
Después, necesitas otra regla en el conjunto de reglas SNMPv3 contexts to use in requests. Aquí seleccionas el check plugin para el que deben activarse los contextos y, a continuación, la lista de contextos que deben consultarse en la monitorización.
Por suerte, hay muy pocas situaciones en las que tengas que trabajar con contextos, porque desgraciadamente no es posible que la monitorización los reconozca automáticamente. Siempre es necesaria una configuración manual de los contextos.
5. Rendimiento y calendario
5.1. Inline-SNMP
El rendimiento siempre juega un papel importante -especialmente en entornos con muchos host- y la monitorización con SNMP consume más CPU y memoria que con los agentes Checkmk.
Mientras que Checkmk edición Raw realiza solicitudes SNMP de la forma clásica mediante los comandos snmpget o snmpbulkwalk, las ediciones comerciales tienen un motor SNMP integrado que realiza las solicitudes SNMP de forma muy eficiente sin generar ningún proceso adicional. Con esto, la carga de la 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 Checkmk necesarios simultáneamente y, por tanto, la carga de memoria.
5.2. Intervalos de chequeo para las comprobaciones SNMP
Si tus recursos alcanzan sus límites, o si tardas más de 60 segundos en sondear un único dispositivo, puedes reducir el intervalo en el que Checkmk consulta al host o hosts. Con el conjunto de reglas Normal check interval for service checks, que aplicas específicamente a los servicios Checkmk de los hosts, puedes ampliar el intervalo general de un minuto a, por ejemplo, 2 ó 5 minutos.
Especialmente para las comprobaciones SNMP, también existe el conjunto de reglas Check intervals for SNMP checks. Esto te permite reducir el intervalo para los check plugin individuales. Es importante saber que nunca puedes establecer el intervalo a un tiempo superior al intervalo para la monitorización general por parte del servicio Checkmk.
En general, sin embargo, recomendamos que la monitorización se diseñe de modo que pueda mantenerse el intervalo estándar de un minuto, y que sólo se aumente en casos excepcionales para host o checks individuales.
5.3. Ajustes de tiempo para el acceso SNMP
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 los dispositivos que responden muy lentamente, o a los que sólo 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 consiste en muchas solicitudes separadas. Por lo tanto, el timeout total es un múltiplo de los ajustes especificados aquí.
5.4. Pasarela: Número de OID por bulk
Por defecto, SNMP transmite 10 respuestas en un paquete por cada solicitud a GetBulk. Prueba el conjunto de reglas experimentales Bulk walk: Number of OIDs per bulk para ver si un valor más alto funciona mejor. Sin embargo, esto sólo ocurrirá cuando se transfieran grandes tablas al host, por ejemplo, si se trata de un switch con muchos puertos.
SNMP siempre llena los paquetes hasta el número especificado, incluyendo los registros que siguen a los realmente necesarios. Y si sólo se necesitan realmente unos pocos de estos registros, se transfieren datos extra inútilmente y aumenta la sobrecarga.
Por otra parte, en la práctica puede ocurrir ocasionalmente que los dispositivos con el valor por defecto de 10 OID por paquete masivo tengan problemas, en cuyo caso puede ser útil reducir el número.
5.5. Limitar los rangos de OID SNMP
Normalmente, Checkmk funciona obteniendo siempre la información de todos los puertos del switch, aunque no todos estén siendo monitorizados realmente. De todas formas, esto es bueno, ya que normalmente es más rápido porque no se pueden hacer consultas individuales con las eficientes consultas masivas. Además, desde nuestro punto de vista, siempre es recomendable monitorizar todos los puertos para encontrar puertos defectuosos o cables con altas tasas de error. Si los puertos no están UP de forma fiable, también puedes marcar el estado de enlace DOWN como OK.
Sin embargo, hay casos aislados en los que los switches tienen muchos puertos y que, por alguna razón, responden muy lentamente o procesan SNMP de forma muy ineficiente, de modo 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 estáticamente la lista de datos consultados (por ejemplo, puertos). En el valor de la regla, para cada check plugin concreto especificas qué índices de la tabla respectiva deben consultarse.
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 sólo se obtienen los dos primeros puertos a través de SNMP:
Nota: Este filtrado se realiza antes del descubrimiento de servicios y de la monitorización. Dependiendo de la configuración de Network interface and switch port discovery, esto no significa automáticamente que estos dos puertos vayan a ser monitorizados.
6. Simulación mediante paseos SNMP
6.1. Principio
El motor SNMP de Checkmk tiene una función muy útil: puedes hacer que un dispositivo monitorizado escriba una instantánea completa de todos sus datos SNMP en un archivo, un paseo SNMP. Puedes utilizar este archivo más tarde para simular la monitorización del dispositivo en otro servidor Checkmk, aunque este otro servidor no tenga conexión de red real con el dispositivo.
Utilizamos esta función de forma muy intensiva, por ejemplo, cuando nuestro equipo de soporte desarrolla nuevos check plugin para nuestros clientes, por lo que nuestros desarrolladores no necesitan acceder a tus dispositivos, sólo un paseo SNMP.
6.2. Crear una visita a través de la GUI
Puedes crear un walk SNMP directamente desde la GUI. La función se encuentra en el menú contextual del servicio Checkmk de los host y también en el menú de los host (entrada Download SNMP walk):
La creación del paseo tarda unos segundos en el mejor de los casos, pero no es raro que tarde unos minutos. Cuando la creación esté terminada, puedes descargar el archivo creado a través de la línea Result.
6.3. Crear un paseo desde la línea de comandos
También puedes crear paseos desde la línea de comandos. Conéctate al site desde el que se está monitorizando el dispositivo. La creación del paseo se hace simplemente con el comando cmk --snmpwalk y el host especificado (que debe estar configurado en monitorización):
OMD[mysite]:~$ cmk --snmpwalk switch23Utiliza también el interruptor -v para ver una salida más detallada sobre el progreso:
OMD[mysite]:~$ cmk -v --snmpwalk switch23
switch23:
Walk on ".1.3.6.1.2.1"...3664 variables.
Walk on ".1.3.6.1.4.1"...5791 variables.
Wrote fetched data to /omd/sites/mysite/var/check_mk/snmpwalks/switch23.El archivo se colocará en el directorio var/check_mk/snmpwalks, donde lleva simplemente el nombre del host. Es un archivo de texto. Si tienes curiosidad, puedes verlo -por ejemplo, con less- y salir del programa con la tecla Q:
OMD[mysite]:~$ less var/check_mk/snmpwalks/switch23
.1.3.6.1.2.1.1.1.0 Yoyodyne Frobolator 23 port L2 Managed Switch
.1.3.6.1.2.1.1.2.0 .1.3.6.1.4.1.11863.1.1.3
.1.3.6.1.2.1.1.3.0 560840147
.1.3.6.1.2.1.1.4.0 Zoe Zhang El comando cmk --snmpwalk tiene algunas opciones más útiles:
| Opción | Efecto |
|---|---|
|
Cuando Checkmk realiza un recorrido en un host, generalmente recupera dos subárboles del área de datos SNMP. Éstos se especifican en el árbol SNMP mediante los llamados OID (identificadores de objetos). Éstos son |
|
Esta opción es similar a |
|
La opción |
|
|
6.4. Utilizar los recorridos guardados para simulaciones
Si quieres utilizar este recorrido en un sitio Checkmk diferente (o el mismo) para una simulación, guarda el archivo del recorrido con el nombre del host en este sitio en var/check_mk/snmpwalks. Asegúrate de que el usuario del site es el propietario del archivo y de que los permisos están establecidos en 0600 (sólo 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 al host o hosts afectados.
A partir de ahora, sólo se utilizará el archivo guardado para supervisar el 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 redirigirlos simplemente al servidor Checkmk indicando la dirección IP 127.0.0.1 a los hosts.
7. Archivos y directorios
| Ruta del archivo | Descripción |
|---|---|
|
Aquí se generan los archivos SNMP walk o también se esperan si quieres utilizarlos para simular datos SNMP. |