Monitorización: Checkmk series vol I – Instalación

¿Qué es Checkmk y para qué sirve?

Checkmk es una herramienta de monitoreo integral diseñada para ayudar a los administradores de sistemas a supervisar el rendimiento, la disponibilidad y la salud de su infraestructura de TI. Desde servidores, redes y aplicaciones hasta servicios en la nube y entornos de virtualización, Checkmk ofrece un análisis detallado y en tiempo real de cada uno de estos componentes, facilitando la detección de problemas y la toma de decisiones para optimizar el rendimiento del sistema.

Objetivo de este artículo

En este artículo, exploraremos cómo instalar Checkmk en un contenedor de Debian 12 en Proxmox. Además, configuraremos una IP pública y le asignaremos un dominio para facilitar el acceso y la gestión de Checkmk desde cualquier ubicación. A lo largo de esta guía, detallaremos los pasos de instalación y configuración necesarios para implementar esta herramienta en un entorno virtualizado de manera segura y accesible.

Consideraciones Previas

Es importante señalar que la instalación del contenedor Debian para Checkmk en Proxmox no es completamente directa. Durante el proceso, será necesario realizar algunos ajustes manuales que pueden desviar ligeramente de una instalación completamente limpia y automatizada. Sin embargo, una vez superados estos pequeños obstáculos, el funcionamiento de Checkmk será estable y confiable, cumpliendo con todas las expectativas para el monitoreo eficiente de nuestra infraestructura.

Preparación del contenedor

Comenzaremos con una configuración inicial del contenedor Debian que nos permitirá poner en marcha Checkmk de manera funcional. Estos ajustes serán modestos y adecuados para comenzar, aunque es importante tener en cuenta que, a medida que el monitoreo se expanda y se añadan más equipos, Checkmk requerirá más recursos para gestionar la carga adicional de los nuevos checks.

Es posible que, en determinado momento, la infraestructura crezca tanto que se haga necesario levantar un segundo nodo. Esto permitirá distribuir la carga de trabajo, optimizando el rendimiento y asegurando que cada dispositivo en la red sea monitorizado eficientemente.

Una vez dentro de la interfaz de Proxmox (vamos a usar la versión 8) hacemos click en crear CT (contenedor):

Usaremos una imagen de Debian 12 previamente bajada de las oficiales de Proxmox.

30 GB para empezar sera mas que suficiente.

4 GB quizás sea demasiado, pero no me gusta pecar de poca RAM, por otra parte quito SWAP como manía porque son discos NVME y no quiero que se deterioren prematuramente, pero esto es preferencia personal.

Los datos que se muestran a continuación los dejo a modo de ejemplo de como se configuraria un contenedor en un nodo de Proxmox en un proveedor real, en este caso OVH. Hay que tener en cuenta varias cosas aqui:

• La dirección MAC no es algo baladí; es la que indica al switch que la IP que estamos configurando se dirige a este contenedor en concreto.
• La puerta de enlace la proporciona el proveedor, pero suele ser la 254 del rango en el que se encuentra el nodo de Proxmox.
• A la IP asignada se le llama una IP failover. En resumen, se pueden contratar IPs adicionales como servicio de manera mensual y adjudicárselas a un servidor. De este modo, el servidor tendrá varias IPs asignadas además de la primaria, las cuales se pueden usar para los contenedores o VMs.

El contenedor usará las DNS de Cloudflare (1.1.1.1) y las de Google (8.8.8.8) como genéricas, ya que no tenemos necesidades de DNS internas o especiales.

Confirmamos en la siguiente y encendemos el contenedor.

Conexión al contenedor

Personalmente, me conecto por SSH al contenedor. Como hemos visto, añadí una clave pública durante la instalación, así que podré conectarme de esta manera al mismo. En este caso, no profundizaré en las buenas prácticas que deberían aplicarse para la configuración de SSH.

Si no añades la clave pública, siempre podrás conectarte desde tu nodo de Proxmox listando los contenedores con pct list y luego usando pct enter <<id del contenedor>>.

Conectare con el siguiente comando, pero este solo sería mi caso, lo dejo a modo ejemplo.

ssh checkmk.iesvjp.desarrollo.ovh -lroot -i /home/elk/.ssh/id_rsa_macbook

Aquí hay varias cosas que explicar. Una es el uso del dominio checkmk.iesvjp.desarrollo.ovh, que es un subdominio de prueba. Antes de empezar con la instalación, asigné el A-record de este subdominio a la IP que estamos usando con el servidor de Proxmox (178.33.90.22).

Por otra parte, la clave asignada en el proceso de instalación no es la clave por defecto de la máquina que estoy usando, así que debo elegir manualmente la clave que quiero usar o manipular el archivo de configuración de SSH en mi usuario (~/.ssh/config).

Actualización del contenedor

Algo que hago habitualmente siempre que instalo un sistema operativo es actualizarlo completamente a la última versión de los paquetes. En Debian, esto se realiza con apt update y apt upgrade.

Instalación de Checkmk

Ahora vamos a descargar Checkmk.

Primero, debemos ir a la página oficial de Checkmk: https://checkmk.com/download. Aquí, en el punto número 1, seleccionaremos la versión RAW edition, que es 100% gratuita y sin limitaciones (aunque carece de algunas características interesantes de la versión gratuita, esta última tiene un límite de equipos a monitorizar).

En la parte 2, «Choose platform», elige la última versión, luego Debian y finalmente versión 12.

Una vez hecho esto, el sitio proporcionará una serie de instrucciones. Reproduciré la mayoría de ellas a continuación, pero es importante tener en cuenta que, si este tutorial queda desactualizado, las versiones podrían variar…

# Cambiamos de directorio a temporales por ejemplo
cd /tmp

# descargamos el paquete
wget https://download.checkmk.com/checkmk/2.3.0p20/check-mk-raw-2.3.0p20_0.bookworm_amd64.deb

Luego instalamos el paquete:

apt install ./check-mk-raw-2.3.0p20_0.bookworm_amd64.deb

Aparecerá algo parecido a esto:

Le damos a que si y esperamos a que termine de bajar los paquetes necesarios y se instale. Una vez terminado podemos probar si instalo correctamente escribiendo omd version.

Si devuelve la versión sería tan facil como crear nuestro nuevo sitio de monitorización de checkmk escribiendo omd create <<nombre>>. Por ejemplo en mi caso omd start monitor.

Luego debemos inicializar el proceso con omd start <<nombre>>, en mi caso omd start monitor. Si todo fue correctamente deberías de ver una pantalla parecida a la anterior.

Entonces, y teniendo en cuenta las instrucciones anteriores, tendríamos el sitio disponible, en mi caso, en: http://checkmk.iesvjp.desarrollo.ovh/monitor. El problema aquí es el uso del protocolo HTTP, es decir, sin certificado de seguridad. Esto no es admisible para un sitio de estas características.

Securizar servidor Apache

Para asegurar el sitio, aprovecharemos que tenemos una IP pública y que existen certificados gratuitos que podemos solicitar. Para esto, usaremos Certbot, una herramienta desarrollada por la Electronic Frontier Foundation (EFF), una organización sin ánimo de lucro dedicada a la defensa de los derechos digitales. La EFF, mediante iniciativas como Certbot y el servicio gratuito de Let’s Encrypt, facilita el acceso a certificados SSL gratuitos, permitiendo a sitios web como el nuestro mejorar la seguridad sin costos adicionales.

Primero, activaremos los módulos necesarios en Apache:

a2enmod ssl rewrite headers

Luego, instalamos Certbot junto con el complemento para Apache:

apt install certbot python3-certbot-apache -y

Por último, ejecutamos Certbot para solicitar y configurar automáticamente el certificado SSL:

certbot --apache

Por último reiniciamos Apache

systemctl restart apache2

Si vamos a https://checkmk.iesvjp.desarrollo.ovh/monitor ahora si vemos que tenemos el protocolo https habilitado. Este certificado expira a los meses de uso y necesita ser renovado manualmente ¿o no? Quizás seria bueno que mirases como automatizar esta pequeña tarea.

Con esto ya veriamos una pantalla similar a esta:

Esta es la pantalla principal del dashboard de Checkmk. Aquí tienes una breve descripción de cada sección y su función:

• Host Statistics (Estadísticas de Hosts): En esta sección, se muestra el estado general de los hosts (equipos o servicios) que se están monitoreando. Incluye categorías como:
  • Up: Hosts en funcionamiento.
  • In downtime: Hosts que están en un período de inactividad planificada.
  • Unreachable: Hosts que no son accesibles.
  • Down: Hosts que están caídos.
  • Total: El número total de hosts.

• Service Statistics (Estadísticas de Servicios): Aquí se presentan los estados de los servicios en los hosts monitoreados, clasificados en:
  • OK: Servicios funcionando correctamente.
  • In downtime: Servicios en mantenimiento.
  • On down host: Servicios que están en hosts caídos.
  • Warning: Servicios con alertas de advertencia.
  • Unknown: Estado desconocido de algunos servicios.
  • Critical: Servicios en estado crítico que necesitan atención.

• Service Problems (Problemas de Servicios) y Host Problems (Problemas de Hosts): Estas secciones listan problemas no gestionados o no atendidos en los servicios y hosts. Aquí puedes ver detalles sobre el estado, íconos de alerta, y un resumen del problema, aunque en esta captura no se muestran problemas activos.
• Overview (Resumen): En la parte derecha, se ofrece un resumen rápido del número de hosts, servicios y eventos no gestionados.
• Master Control: Permite realizar ajustes o intervenciones en el monitoreo general.

Esta pantalla es el punto central para obtener una vista general del estado de la infraestructura que estás monitoreando con Checkmk. Desde aquí, puedes identificar rápidamente problemas en hosts o servicios y acceder a los detalles necesarios para su resolución.

Añadiendo nuestro primer host

Una vez hecho esto, vamos añadir nuestro primer host (o equipo a monitorizar) y ¿Que mejor que el propio checkmk? a fin de cuentas probablemente sea interesante monitorizarlo. ¿Quizas sea interesante en un sentido y en otro no? Te dejo que lo pienses.

Para añadir un host debes ir en la barra lateral a «Setup» > «Agents > Linux» > «Packaged Agents > Linux», boton derecho encima copiar enlace.

Este enlace te da el «Agente de checkmk«, no confundir el agente con el «Servidor de checkmk», el agente se usa para añadirlo como servicio a los hosts que quieres añadir para monitorizar, hay mas maneras segun el tipo de equipo, pero para un host linux esta es la manera mas adecuada. Asi que vamos a instalar el agente.

Ve a la linea de comandos otra vez y:

cd /tmp

# Bajar agente
wget https://checkmk.iesvjp.desarrollo.ovh/monitor/check_mk/agents/check-mk-agent_2.3.0p20-1_all.deb

# Instalar agente
apt install /tmp/check-mk-agent_2.3.0p20-1_all.deb

Después de instalar el agente, es necesario realizar algunos cambios, ya que estamos instalando Checkmk en un contenedor LXC, lo cual requiere ciertos ajustes en los servicios que se instalan por defecto. Aunque puede parecer algo trabajoso, estos cambios son sencillos de aplicar.

Primero, debemos editar el archivo del servicio cmk-agent-ctl-daemon:

nano /lib/systemd/system/cmk-agent-ctl-daemon.service

En este archivo, añadimos a ExecStart

[Service]
ExecStart=/usr/bin/cmk-agent-ctl daemon -P 6556

Tambien comentamos las siguientes líneas para evitar restricciones de permisos en el contenedor LXC:

# added v232
#ProtectControlGroups=yes
ProtectKernelModules=yes
#ProtectKernelTunables=yes

Finalmente, recargamos el demonio de systemd y reiniciamos el socket del agente para aplicar los cambios:

systemctl daemon-reload
systemctl restart check-mk-agent.socket
systemctl restart check-mk-agent-async.service
systemctl restart cmk-agent-ctl-daemon.service

Configuración de nuestro primer host en checkmk

Debemos hacer click en «Setup» y luego en «Add host to the monitoring».

Ponemos como host el nombre en este caso checkmk.iesvjp.desarrollo.ovh y como ipv4 el host 127.0.0.1 para evitar consultas DNS, esto es porque el, esta chequeandose a si mismo. Pulsamos el botón de «Rescan» y luego cuando salgan los servicios el de «Monitor undecided services«.

Como vemos encuentra bastantes cositas:

Veras que arriba a la derecha saldran cambios pendientes de guardar. Haz click en ese botón y finalmente salva los cambios. Despues click en «Monitor» > «Main dashboard». Te encontrarás algo parecido a esto:

Aquí es donde aprenderás una lección valiosa. Tienes un host recién instalado, en el que, en teoría, todo debería estar funcionando bien. Sin embargo, no puedes saber con certeza si realmente está bien solo por asumirlo. Las suposiciones no son nada en el mundo del monitoreo.

En esta pantalla puedes ver claramente que tienes 2 fallos críticos. Dependiendo de cómo hayas seguido este manual, podrías tener un fallo menos, pero el mensaje es claro: las cosas deben comprobarse de manera empírica. No podemos dar por hecho que algo está bien simplemente porque parece estar funcionando. La monitorización nos ayuda a verificar que cada servicio y configuración está en orden, brindándonos evidencias concretas sobre el estado real de nuestro sistema.

Registrando nuestro agente con certificado SSL

Uno de los fallos que tenemos es:

Check_MK Agent:
Version: 2.3.0p20, OS: linux, TLS is not activated on monitored host (see details)WARN, Agent plug-ins: 0, Local checks: 0

Este problema se soluciona registrando el servidor en Checkmk con un certificado que cifre la comunicación. Aunque la lógica de monitoreo dentro del propio host es limitada, es crucial implementar esta seguridad, especialmente para los sitios expuestos a internet.

Si haces un telnet a localhost 6556, verás que se muestra toda la información del Checkmk. Lo preocupante es que, si cualquier otro host con acceso a este servidor ejecuta el mismo comando y el servidor tiene acceso público en internet, cualquiera podría obtener esta información (si sabe la IP pública y el puerto 6556). Esto representa un riesgo de seguridad importante.

Para mitigar este riesgo, debemos registrar el host en el servidor Checkmk utilizando un certificado que cifre la conexión. Para ello, ejecuta el siguiente comando:

cmk-agent-ctl register --hostname checkmk.iesvjp.desarrollo.ovh --server localhost --site monitor --user cmkadmin

Este paso asegurará que la comunicación entre el agente y el servidor esté protegida, evitando la exposición de datos sensibles.

Vuelve, veras que ya te sale en verde la validacion y no en amarillo.

Ademas si haces telnet a localhost 6556 nuevamente veras que no hay respuesta:

Tambien te sale un fallo con el servicio systemd-networkd, este servicio no es necesario para el contenedor y lo mejor es desactivarlo:

# Detiene y enmascara el servicio y el socket en un solo paso
systemctl stop systemd-networkd systemd-networkd.socket
systemctl mask systemd-networkd systemd-networkd.socket

Servicios autodetectados por Checkmk

A estas alturas ya debes tener mas o menos esto:

Algunos elementos resultan especialmente llamativos, considerando que estamos en un entorno de contenedor, que generalmente no gestiona ciertos recursos de manera directa.

• Servicios OMD (Open Monitoring Distribution): Estos servicios son específicos de Checkmk y proporcionan datos sobre el rendimiento y uso de recursos dedicados al propio entorno de monitoreo. Incluyen:
  • OMD monitor apache: Muestra el rendimiento del servidor Apache usado para el portal de Checkmk, con detalles sobre el número de solicitudes y el tiempo de respuesta.
  • OMD monitor disk usage: Indica el uso del disco asignado al entorno de Checkmk, incluyendo el espacio usado para inventarios, logs, y otros archivos relacionados.
  • OMD monitor Event Console: Indica que el sistema de eventos está en funcionamiento, aunque sin eventos activos en este momento.
  • OMD monitor status y performance: Proporcionan información sobre el estado general del sistema de monitoreo y el rendimiento de los checks.
  La presencia de estos servicios OMD es significativa porque permiten monitorear el rendimiento y uso de recursos del propio sistema de Checkmk desde dentro del contenedor, una funcionalidad avanzada para un LXC.

Es decir, el checkmk se detecta a si mismo con el cliente y saca estadisticas valiosas y estado de los servicios asociados de manera automatica.

Especialmente llamativo es que no hemos configurado ninguna RAID pero detecta lo siguiente:

• MD Softraid (md2, md3, md5): Los servicios que monitorean el estado del RAID son también notables, ya que generalmente los contenedores LXC no interactúan con el almacenamiento físico directamente, sino que dependen del sistema anfitrión. La capacidad de monitorear configuraciones RAID dentro del contenedor sugiere que Checkmk tiene visibilidad sobre el estado del almacenamiento en el nivel del host, lo cual es poco común en un contenedor y puede ser de gran utilidad.

Es decir, esta detectando las RAID del Proxmox, no del servidor de Checkmk, esto no es util, en todo caso habría que monitorizarlo a nivel de nodo de Proxmox así que lo logico sería quitarlos de aqui.

Hay que hacer click en la linea de puntos y «Parameters of this service» una vez dentro buscar «Disabled services» rellenar tal que asi:

Todavía por ver

Este es solo el principio, todavía queda mucho por contar, por ejemplo:

• Añadir metodos de comunicación de alertas
• Enlazar otros hosts con checkmk
• Añadir plugins
• Hacer nuestros propios chequeos personalizados
• Configurar backups y restauración de la configuración de Checkmk
• Personalización de dashboards y vistas
• Labels, Grupos…
• Monitorización de servicios específicos…