Monitorización: Checkmk series vol II

ISO

Ha pasado bastante tiempo desde la última sesión, así que vamos a realizar tareas de mantenimiento y actualización.

También es importante recordar que en la última sesión vimos que todo esto está instalado en un entorno de virtualización con Proxmox.

Si tienes la posibilidad, haz un snapshot (instantánea) o una copia de seguridad antes de comenzar. De esta manera, si algo sale mal durante el proceso, siempre podrás restaurar el sistema a un estado anterior sin complicaciones.

Actualización del sistema y CheckMK

Recuerdo que estábamos trabajando con Debian 12, por lo que primero actualizaremos el sistema:

# Actualizar Debian
apt update
apt upgrade

A continuación, visita la página oficial de Checkmk para descargar la última versión disponible. Nosotros estábamos utilizando la edición RAW, que es completamente gratuita y compatible con Debian 12. Deberías encontrar algo similar a esto en la web.

Esto te dará un enlace de descarga parecido a este:

https://download.checkmk.com/checkmk/2.3.0p28/check-mk-raw-2.3.0p28_0.bookworm_amd64.deb

La actualización de la monitorización sería en este caso así:

# Descargar nueva versión
cd /tmp
wget https://download.checkmk.com/checkmk/2.3.0p28/check-mk-raw-2.3.0p28_0.bookworm_amd64.deb

# Instalar paquetería
apt install ./check-mk-raw-2.3.0p28_0.bookworm_amd64.deb

Con esto tienes lo necesario para empezar, pero ahora hay que actualizar el checkmk realmente. Esto es solo la preparación. Hay que tener en cuenta que puedes tener varios checkmk en el sistema y cada uno esta encapsulado, así que una vez tienes la paquetería tienes que elegir actualizar.

# Parar checkmk
omd stop

# Si eres de memoría efímera como yo puedes listar los sitios disponibles
root@checkmk:/tmp# omd sites
SITE             VERSION          COMMENTS
monitor          2.3.0p20.cre

omd update monitor

Este último comando iniciará un wizard tal que así:

Después de esto simplemente ejecutar omd start monitor. Si todo fue bien puedes comprobar el estado del checkmk con omd status.

Una vez te entras por web en tu checkmk normalmente encontrarás siempre estos dos distintivos después de actualizar:

Por un lado, Checkmk te avisa cuando hay cambios pendientes de aplicar (en la parte superior). Por otro lado, es importante revisar las notas del parche (en la parte inferior), ya que podrían advertirte sobre incompatibilidades con plugins antiguos u otros problemas tras la actualización.

Los cambios tendrás que activarlos, y el change log revisarlo. Con esto tenemos la actualización lista.

Métodos de notificación

Evidentemente, un sistema de monitorización pierde gran parte de su utilidad si requiere supervisión constante. Para evitar esto, Checkmk ofrece diferentes opciones de notificación que te alertan automáticamente en caso de que surja un problema en un host.

Tienes que dirigirte a Setup -> Notificaciones como ves en la siguiente imagen.

El método por defecto siempre es el correo electrónico.

Puedes mirar las opciones en el icono de editar.

1️⃣ Método de notificación:

  • En el campo «Notification Method», puedes seleccionar cómo se enviarán las alertas. En este caso, está configurado para enviar notificaciones por correo electrónico en formato HTML.

2️⃣ Parámetros de la notificación:

  • Justo debajo, hay varias opciones avanzadas que permiten personalizar la notificación, como:
    • Dirección del remitente (From).
    • Dirección de respuesta (Reply to).
    • Asunto para notificaciones de host y servicio.
    • Inclusión de información adicional y gráficos en el mensaje.
    • Envío de notificaciones individuales a cada destinatario o en formato agrupado.

3️⃣ Selección de contactos:

  • Aquí se define quién recibirá las notificaciones. Se puede optar por notificar a todos los contactos asociados al host o servicio afectado o a todos los usuarios registrados en Checkmk.

Un aspecto importante a tener en cuenta es que Checkmk enviará los correos de notificación utilizando sendmail con el nombre del hostname del servidor. Esto significa que debes asegurarte de que el sistema tenga configurado correctamente el envío de correos.

Además, para que los correos lleguen correctamente a su destino, es necesario cumplir con las reglas mínimas de verificación de correo. Entre ellas:

  • Un hostname verificable (resoluble mediante DNS).
  • Reglas SPF, DKIM y DMARC configuradas correctamente en los registros DNS del dominio, para evitar que los correos sean marcados como spam.

Si el servidor de Checkmk no está configurado adecuadamente, los correos pueden ser rechazados o terminar en la bandeja de spam del destinatario.

Personalmente a mi me gusta usar un servidor de chat con diferentes canales para diferentes tipos de notificaciones o servicios por ejemplo con Mattermost que es una solución gratuita y que se puede implementar de manera eficaz tanto en móvil como en equipo de escritorio. La opción sería la misma que la de Slack mediante webhook. Dejo una imagen de una configuración de ejemplo:

Y como se vería una alerta:

La imagen muestra una integración de Checkmk con Mattermost, donde se reciben notificaciones automáticas sobre el estado de los servicios monitorizados.

Ejemplo de alerta:

  • En la parte superior, se muestra una notificación de problema (WARNING).
  • El mensaje indica que el servicio Repository database en el host bw01 ha alcanzado un umbral de uso del 80%, lo que activa una advertencia.
  • Se proporciona información adicional sobre el estado y un aviso dirigido a un usuario específico para que revise el problema.

Ejemplo de recuperación:

  • Más abajo, se ve una notificación de recuperación (OK).
  • Indica que el problema anterior ha sido resuelto y que el servicio ha vuelto a la normalidad.

Checkmk permite configurar alertas personalizadas para distintos escenarios, como el monitoreo del espacio en disco, la carga del sistema o el estado de servicios críticos. En este caso, se ha configurado para enviar alertas sobre el uso del almacenamiento de una copia de seguridad.

Más adelante, exploraremos cómo personalizar estos checks y las notificaciones en función de las necesidades del sistema.

Por supuesto se pueden añadir plugins personalizados de notificación para virtualmente cualquier sistema que quieras.

Organización de sistemas

En Checkmk, la organización de los equipos monitorizados se gestiona principalmente a través de carpetas y labels (etiquetas). Estos mecanismos permiten estructurar los hosts de manera eficiente, facilitando la administración y aplicación de configuraciones específicas.

Carpetas: Estructuración jerárquica

  • Funcionan como contenedores de hosts y pueden anidarse en una jerarquía.
  • Permiten aplicar configuraciones comunes a todos los hosts dentro de una carpeta.
  • Se pueden usar para organizar los hosts por ubicación, función o cliente, por ejemplo:
├── Producción
│   ├── Servidores Web
│   ├── Bases de Datos
│   ├── Backups
├── Desarrollo
│   ├── Pruebas
│   ├── Integración

Ejemplo de uso: Si necesitas que todos los servidores en «Producción» usen el mismo grupo de notificaciones o reglas de monitoreo, simplemente configuras la carpeta y todos los hosts heredarán esas reglas.

Labels (Etiquetas): Clasificación flexible

  • Son asignaciones de metadatos que permiten etiquetar los hosts con información clave.
  • A diferencia de las carpetas, los labels no están ligados a una jerarquía, por lo que un mismo host puede tener múltiples etiquetas.
  • Se utilizan en filtros y reglas de notificación para aplicar configuraciones dinámicas.

¿Cuándo usar Carpetas y cuándo Labels?

  • Carpetas → Para agrupar hosts bajo configuraciones comunes y aplicar reglas de forma jerárquica.
  • Labels → Para clasificar hosts sin depender de la estructura jerárquica y definir reglas más flexibles.

Algunos ejemplos prácticos

Los labels pueden usarse para identificar distintos tipos de máquinas, como contenedores LXC y máquinas virtuales QEMU. Por ejemplo, en los LXC puedes evitar que hereden servicios redescubiertos del host que los alberga, como la monitorización de la RAID.

Las carpetas pueden servir para organizar los nodos de un clúster de Proxmox y aplicar reglas específicas a todos ellos. También pueden utilizarse para asignar de forma centralizada credenciales de IPMI a un grupo de hosts.

Algunas de estas opciones se pueden aplicar mediante reglas, que veremos en el siguiente punto.

Introducción a las reglas

En Checkmk, prácticamente todas las configuraciones están gobernadas por reglas. De hecho, el envío de correos es un ejemplo claro de esto: es simplemente una regla más dentro del sistema.

Las reglas afectan a todos los aspectos de la monitorización, permitiendo una personalización extrema. Puedes aplicarlas a labels, modificar el comportamiento de un host en cualquier de sus secciones, o incluso alterar la forma en que se descubren y gestionan los servicios en la infraestructura.

Algunas posibilidades clave incluyen:

  • Aplicar reglas a etiquetas (labels) para que ciertos tipos de máquinas se comporten de manera distinta (por ejemplo, desactivar la herencia de servicios en contenedores LXC).
  • Definir reglas a nivel de host, permitiendo excepciones y configuraciones específicas independientemente de la carpeta en la que se encuentre.
  • Crear entornos dinámicos de autodescubrimiento, donde Checkmk detecte y gestione servicios sin intervención manual.
  • Modificar la frecuencia de comprobaciones, los umbrales de alerta o incluso cómo se reportan los eventos según el contexto del host o del servicio.

Este sistema de reglas hace que Checkmk sea extremadamente flexible, permitiendo adaptar la monitorización a entornos complejos con necesidades específicas.

Vamos a hacer un pequeño simulacro de esto. En el menu vamos a Monitor -> All Hosts

Una vez aquí vamos a elegir cualquier host y con el host seleccionado tendremos algo así:

Selecciona un servicio por ejemplo yo usaré «CPU utilization». La pantalla mostrará algo así:

Esta sección por supuesto continua hacia abajo, que habrá muchas mas reglas, esta es solo una sección de las múltiples que te encuentras reglas. Cualquiera de ellas es susceptible de ser cambiada, haremos una prueba con la que pone «Delay service notifications«.

Click en «Add rule» .

La imagen muestra la pantalla de configuración para retrasar notificaciones en Checkmk, nada demasiado útil, pero usable cuando un servicio presenta problemas. Este tipo de reglas es útil para evitar alertas inmediatas por fluctuaciones temporales y solo enviar notificaciones si el problema persiste.

He añadido una configuración de ejemplo:

Explicación de los campos en la configuración

1️⃣ Nombre de la regla → Un identificador para reconocer la regla fácilmente. Se recomienda un nombre descriptivo.

2️⃣ Comentario → Campo opcional para añadir una descripción o anotaciones que ayuden a comprender el propósito de la regla.

3️⃣ Tiempo de retraso → Define cuánto tiempo debe transcurrir antes de que se envíe una notificación. En este caso, la notificación se retrasará 5 minutos. Si el servicio vuelve a la normalidad antes de ese tiempo, no se enviará ninguna alerta. Esto sería útil si ese servicio por ejemplo flapea demasiado frecuentemente y no es algo importante.

4️⃣ Condiciones de la regla → Se define el tipo de condición que debe cumplirse para que la regla se aplique. Aquí se están usando «Explicit conditions», lo que significa que la regla solo afectará a los hosts y servicios especificados.

5️⃣ Host específico → Se ha seleccionado el host checkmk.iesvjp.desarrollo.ovh. La regla solo se aplicará a este equipo ¡Pero puedes elegir que sea una regla general para todos!

6️⃣ Servicio afectado → Se ha definido ^CPU utilization.*, lo que significa que la regla se aplicará a cualquier servicio cuyo nombre empiece con «CPU utilization». Se usan expresiones regex.

Este es un claro ejemplo del potencial y la flexibilidad que ofrece Checkmk. Su sistema de reglas permite controlar prácticamente cualquier aspecto de la monitorización, adaptándolo a necesidades específicas.

Existen reglas para todo tipo de configuraciones, entre ellas:

  • Frecuencia de chequeos → Controlar cada cuánto tiempo se revisa un servicio.
  • Tiempo de reintento → Definir cuántos intentos se hacen antes de marcar un estado como crítico.
  • Número máximo de checks → Limitar la cantidad de comprobaciones antes de considerar un fallo definitivo.
  • Notificaciones → Especificar quién debe recibir alertas y en qué condiciones.
  • Agregaciones de clústeres → Combinar múltiples servicios en una única vista para evaluar su estado de manera global.
  • Personalización visual → Incluso la asignación de iconos a hosts o servicios se gestiona mediante reglas.

Este enfoque basado en reglas hace que Checkmk sea extremadamente adaptable, permitiendo personalizar la monitorización sin necesidad de intervenciones manuales constantes.

Estos serían solo algunos ejemplos. Seguiremos usándolos en un futuro.