 |
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. Las características especiales del Checkmk Micro Core
Las ventajas más significativas de CMC son su mayor rendimiento y sus tiempos de respuesta más rápidos en comparación con el core de monitorización del proyecto Open Source Nagios. Además, tiene otras ventajas interesantes que debes conocer, siendo las más importantes:
Smart Ping: comprobaciones inteligentes de hosts
Procesos auxiliares Check helper, Checkmk Fetcher y Checkmk Checker
Programación inicial
Proceso de procesamiento de datos de rendimiento
Hay un par de funciones de Nagios que no se utilizan, o que se llevan a cabo mediante un procedimiento diferente en el CMC. Puedes encontrar más detalles al respecto en el artículo sobre la migración al CMC.
2. Smart Ping: comprobaciones inteligentes de hosts
Con Nagios, la disponibilidad de los hosts suele verificarse mediante un Ping.
Para ello, por cada host se ejecuta un Plugin como check_ping o check_icmp una vez por intervalo (normalmente una vez por minuto).
Esto envía, por ejemplo, cinco paquetes de ping y espera a que vuelvan.
Crear los procesos para ejecutar los Plugins consume valiosos recursos de la CPU.
Además, estos pueden acumularse durante bastante tiempo si no se puede acceder a un host, y hay que soportar largos tiempos de timeout.
Por el contrario, CMC realiza comprobaciones de host —a menos que se configure lo contrario— utilizando un procedimiento llamado Smart Ping.
Smart Ping se basa en un componente interno llamado icmpsender, que tiene su propia implementación de ping.
Dado que Checkmk con CMC no depende de un binario externo, no es necesario generar un nuevo proceso por cada paquete de ping enviado.
Además, el comportamiento predeterminado de icmpsender difiere del de su homólogo en Nagios.
En lugar de esperar múltiples paquetes en series rápidas, icmpsender envía solo un paquete ICMP por host cada n segundos (el valor predeterminado es 6 segundos, configurable mediante el conjunto de reglas Normal check interval for host checks).
Este comportamiento reduce drásticamente el consumo de recursos y el tráfico de datos.
No se espera explícitamente a las respuestas a los pings.
El componente «icmpreceiver» del CMC se encarga de decidir si el estado de un host es «UP» o «DOWN».
El CMC trata los paquetes de ping entrantes de un host como una comprobación de host satisfactoria y, por lo tanto, marca el host como «UP».
Si no se recibe ningún paquete de un host dentro de un tiempo definido, este host se marcará como «DOWN».
El timeout está preestablecido en 15 segundos (2,5 intervalos) y se puede cambiar por host con el conjunto de reglas «Settings for host checks via Smart PING».
El componente icmpreceiver también escucha los paquetes TCP SYN (sincronización) y RST (reinicio) procedentes de un host.
Cuando recibe dichos paquetes, se considera que el host está en estado de «UP».
Este mecanismo puede provocar estados inestables en los hosts de infraestructuras en las que no se permite el tráfico ICMP, pero sí el tráfico TCP.
 |
|
2.1. Sin checks de host bajo demanda
Los checks de host no solo sirven para activar notificaciones en caso de un fallo total del host, sino también para suprimir las notificaciones de problemas de servicio durante el tiempo de mantenimiento planificado de un host. Pueden surgir problemas de servicio que no sean responsabilidad del propio servicio, sino más bien de una condición de fallo del host. Puede ocurrir que un host esté realmente «DOWN» (activo) aunque su último estado conocido en Checkmk sea «UP» (inactivo) según el resultado de la última comprobación del host. En tal caso, varias comprobaciones de servicio podrían indicar problemas que dependen del estado «DOWN» del host, lo que provocaría el envío de notificaciones de servicio de forma errónea. Por lo tanto, en caso de un problema de servicio, es importante determinar primero la condición del host del servicio.
El CMC resuelve este problema de forma muy sencilla: si surge un problema con el servicio y el host se encuentra en estado «UP», el CMC esperará a la siguiente comprobación del host. Dado que el intervalo es muy corto (por defecto, solo 6 segundos), el retraso en la notificación es insignificante —si el host sigue en estado «UP» y, por lo tanto, es necesario enviar la notificación para el servicio.
Por ejemplo, tomemos el caso de un Plugin «check_http» que devuelve un estado «CRIT», debido a que el servidor web consultado no está disponible.
En esta situación, tras el inicio de la comprobación del servicio, el componente «icmpreceiver» recibirá un paquete TCP RST (conexión rechazada) de este servidor.
Por lo tanto, el CMC sabe con certeza que el propio host está «UP» y, por lo tanto, puede enviar la notificación sin demora.
Se utiliza el mismo principio al calcular las interrupciones de red si se han definido hosts principales. Aquí también las notificaciones se retrasarán a veces brevemente para esperar a un estado verificado.
2.2. Las ventajas
Este procedimiento ofrece una serie de ventajas:
Una carga de CPU prácticamente insignificante derivada de los checks de los hosts: incluso sin un hardware especialmente potente, se pueden realizar tareas de monitorización para decenas de miles de hosts.
No se interrumpe la monitorización por atascos en los checks de hosts bajo demanda si los hosts están en modo «DOWN».
No hay falsas alarmas de los servicios cuando el estado de un host no está actualizado.
Sin embargo, hay una desventaja que no hay que pasar por alto: los hosts Smart Ping no generan datos de rendimiento (tiempos de ejecución de los paquetes).
En los hosts donde se requieran, puedes simplemente configurar una check activa mediante ping con el conjunto de reglas «Check hosts with PING (ICMP Echo Request)».
2.3. Hosts a los que no se puede hacer ping
En la práctica, no todos los hosts se pueden comprobar mediante ping. En estos casos, también se pueden utilizar otros métodos de CMC para la comprobación del host, por ejemplo, una conexión TCP. Dado que suelen ser excepciones, no tienen ningún impacto negativo en el rendimiento general. El conjunto de reglas aquí es «Host check command».
2.4. Problemas con los cortafuegos
Hay cortafuegos que responden a los paquetes de conexión TCP dirigidos a hosts inaccesibles con un paquete TCP RST. El truco está en que el cortafuegos no puede registrarse como remitente de este paquete, sino que hay que especificar la dirección IP del host de destino. Smart Ping interpretará este paquete como una señal de vida y asumirá erróneamente que el host de destino es accesible.
En una situación así (poco habitual), a través de Global settings > Monitoring core > Tuning of Smart PING tienes la posibilidad de activar la opción «Ignore TCP RST packets when determining host state».
O bien, con check_icmp puedes seleccionar un ping convencional como check de host para los hosts afectados.
3. Procesos auxiliares
Una lección que se puede sacar del bajo rendimiento de Nagios en entornos grandes es que crear procesos es una operación que consume muchos recursos y tiempo. El tamaño del proceso padre es el factor decisivo aquí. Cada vez que se ejecuta una comprobación activa, primero hay que duplicar (bifurcar) todo el proceso de Nagios antes de que sea sustituido por el nuevo proceso: el check plugin. Cuantos más hosts y servicios haya que supervisar, más grande será este proceso y más tardará la bifurcación. Mientras tanto, las demás tareas del núcleo tienen que esperar, y aquí 24 núcleos de CPU no sirven de mucho.
3.1. Check helper
Para evitar bifurcar el núcleo, durante el inicio del programa el CMC crea un número fijo de procesos auxiliares muy ligeros cuya tarea es iniciar los check plugins activos: los check helpers.
Estos no solo se bifurcan mucho más rápido, sino que la bifurcación también se amplía para cubrir todos los núcleos disponibles, ya que el núcleo en sí ya no está bloqueado.
De esta forma, la ejecución de los checks activos (por ejemplo, check_http) —cuyos tiempos de ejecución son en realidad bastante cortos— se acelera considerablemente.
3.2. Checkmk Fetcher y Checkmk Checker
Sin embargo, el CMC va un paso más allá, ya que en un entorno Checkmk las comprobaciones activas son más bien una excepción. Aquí se utilizan principalmente comprobaciones basadas en Checkmk, en las que solo se requiere una única bifurcación por host e intervalo.
Para optimizar la ejecución de estas comprobaciones, el CMC mantiene otros dos tipos de procesos auxiliares: los Checkmk Fetchers y los Checkmk Checkers.
Los Checkmk Fetchers
Los fetchers de Checkmk recogen la información necesaria de los hosts supervisados, es decir, los datos de los serviciosCheck_MK yCheck_MK Discovery . Así, los fetchers se encargan de la comunicación de red con los agentes Checkmk, los agentes SNMP y los agentes especiales. Recopilar esta información lleva algo de tiempo, pero como normalmente se necesitan menos de 50 megabytes por proceso —lo cual es relativamente poca memoria—, se pueden configurar varios procesos sin problemas. Ten en cuenta que los procesos pueden ser swappeados parcialmente o no swappeados en absoluto y, por lo tanto, deben mantenerse siempre en la memoria física. El factor limitante aquí es la memoria disponible en el servidor Checkmk.
|
Los 50 megabytes mencionados anteriormente son una estimación orientativa. El valor real puede ser mayor en circunstancias específicas, por ejemplo, porque se ha configurado IPMI en la placa de gestión. |
Los Checkers de Checkmk
Los Checkmk Checkers analizan y evalúan la información recopilada por los Checkmk Fetchers y generan los resultados de las comprobaciones de los servicios. Los Checkmk Checkers necesitan mucha memoria porque deben incluir la configuración de Checkmk. Un proceso de Checkmk Checker ocupa al menos unos 90 megabytes; sin embargo, puede ser necesario un múltiplo de esta cantidad, dependiendo de cómo estén configuradas las comprobaciones. Por otro lado, los verificadores no generan ninguna carga de red y se ejecutan muy rápidamente. El número de verificadores solo debe ser tan grande como tu servidor Checkmk pueda procesar en paralelo. Por regla general, este número corresponde al número de núcleos de tu servidor. Dado que los verificadores no están limitados por E/S, son más eficaces si cada verificador tiene su propio núcleo.
La división de las dos tareas diferentes, «recoger» y «ejecutar», entre el Checkmk Fetcher y el Checkmk Checker existe desde la versión 2.0.0 de Checkmk. Anteriormente solo había un tipo de proceso auxiliar que se encargaba de ambas: los llamados «Checkmk helpers».
Con el modelo fetcher/checker, ambas tareas se dividen ahora en dos grupos de procesos separados: la recuperación de información de la red con muchos procesos fetcher pequeños y la comprobación, que requiere un gran esfuerzo computacional, con unos pocos procesos checker grandes. Como resultado, un CMC consume hasta cuatro veces menos memoria para el mismo rendimiento (comprobaciones por segundo).
3.3. Configurar correctamente el número de procesos auxiliares
El número de check helpers (comprobaciones activas), Checkmk Fetchers y Checkmk Checkers iniciados por defecto se define en Global settings > Monitoring core y puedes personalizarlo:
Para saber si necesitas cambiar los valores por defecto y cómo hacerlo, tienes varias opciones:
En la barra lateral, el snap-in «Core statistics» te muestra el porcentaje de utilización promediado de los últimos 10-20 segundos:
Para todos los tipos de procesos auxiliares, siempre debe haber suficientes procesos para ejecutar las comprobaciones configuradas. Si un grupo está al 100 % de utilización, las comprobaciones no se ejecutarán a tiempo, la latencia aumentará y los estados de los servicios no estarán actualizados.
La carga no debería superar el 80 % unos minutos después de iniciar un site. Si los porcentajes son más altos, deberías aumentar el número de procesos. Dado que el número necesario de Checkmk Fetchers crece con el número de hosts y servicios de monitorización, lo más probable es que aquí haya que hacer un ajuste. Sin embargo, ten cuidado de crear solo tantos procesos auxiliares como sean realmente necesarios, ya que cada proceso ocupa recursos. Además, todos los procesos auxiliares se inicializan en paralelo al iniciar el CMC, lo que puede provocar picos de carga.
El snap-in «Core statistics» te muestra no solo la carga, sino también la latencia. Para estos valores, se aplica una regla sencilla: cuanto más bajo, mejor; por lo tanto, 0 segundos es lo ideal.
|
También puedes ver los valores que muestra el snap-in para tu site en los detalles del servicio «OMD <site_name> performance». |
Como alternativa al snap-in «Core statistics», también puedes hacer que Checkmk analice tu configuración con Setup > Maintenance > Analyze configuration. La ventaja aquí es que obtienes una evaluación inmediata de Checkmk sobre el estado de los procesos auxiliares. Es muy útil que, si uno de los procesos auxiliares no está en «OK», desde el texto de ayuda puedas abrir la opción correspondiente de «Global settings» para cambiar el valor del proceso.
4. Programación inicial
Durante la programación se define qué comprobaciones deben ejecutarse y en qué momentos. Nagios ha implementado numerosos procedimientos que deberían garantizar que las comprobaciones se distribuyan de forma regular a lo largo del intervalo. Nagios también intentará distribuir las consultas que deben ejecutarse de manera uniforme en un sistema de destino concreto a lo largo del intervalo.
El CMC tiene su propio procedimiento, más sencillo, para este fin. Este tiene en cuenta que Checkmk ya se pone en contacto con un host una vez por intervalo. Además, el CMC garantiza que las nuevas comprobaciones se ejecuten inmediatamente y no se distribuyan a lo largo de varios minutos. Esto resulta muy práctico para el usuario, ya que un nuevo host será consultado tan pronto como se haya activado la configuración. Para evitar que un gran número de nuevas comprobaciones provoque un pico de carga, las nuevas comprobaciones cuyo número supere un límite definible pueden distribuirse a lo largo de todo el intervalo. La opción para ello se encuentra en «Global settings > Monitoring core > Initial scheduling».
5. Proceso de datos de rendimiento
Una función importante de Checkmk es el procesamiento de datos de medición, como la carga de la CPU, y su conservación durante un largo periodo de tiempo. En Checkmk Community, para esto se utiliza PNP4Nagios, que a su vez se basa en RRDtool.
El software realiza dos funciones:
La creación y actualización de las bases de datos Round Robin (RRD).
La representación gráfica de los datos en la GUI.
En una operación básica del core de Nagios, la función mencionada en el punto 1 anterior es un proceso bastante largo.
Dependiendo del método, se utilizan archivos spool, scripts de Perl y un proceso auxiliar (npcd) escrito en C.
Finalmente, los datos parcialmente convertidos se escriben en el socket Unix del daemon de la caché RRD.
El CMC acorta esta cadena escribiendo directamente en el daemon de caché RRD: se prescinde de todos los pasos intermedios. El análisis y la conversión de los datos al formato de RRDtool se realizan directamente en C++. Este método es posible y sensato hoy en día, ya que el daemon de caché RRD ya ha implementado su propio spooling muy eficiente y, con la ayuda de los archivos de registro, esto significa que no se pierden datos en caso de un crash del sistema.
Las ventajas:
Menor carga de E/S de disco y de CPU
Implementación más sencilla con una estabilidad notablemente mayor
El CMC crea nuevos RRD utilizando otro helper, al que se llama mediante cmk-create-rrd.
Este helper crea los archivos bien en un formato compatible con PNP o, alternativamente, en el nuevo formato de Checkmk (solo se aplica a nuevas instalaciones).
Por lo tanto, switchar de Nagios a CMC no afecta a los archivos RRD existentes.
Estos se siguen manteniendo sin problemas.
En las ediciones comerciales, la visualización gráfica de los datos en la interfaz gráfica de usuario (GUI) la maneja directamente la propia GUI de Checkmk, por lo que no interviene ningún componente de PNP4Nagios.