 |
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. Bienvenido a Checkmk para Azure
Tanto si eres un usuario veterano de Checkmk como si nos acabas de descubrir gracias a la disponibilidad de imágenes listas para usar en Microsoft Azure Marketplace, en este artículo encontrarás todos los recursos necesarios para configurar la imagen de máquina virtual preparada y convertirla en un sistema de monitorización que se adapte a tus necesidades.
Si eres nuevo en Checkmk, te recomendamos leer nuestra Guía para principiantes como preparación. Las imágenes de máquina virtual preconfiguradas pueden agilizar muchas tareas durante la instalación, pero tener algunos conocimientos sobre conceptos fundamentales, como los sites, te ayudará durante el proceso de configuración.
1.1. Conceptos básicos
Si eres usuario de Azure, siempre has tenido la opción de añadir Checkmk a una imagen de Ubuntu existente disponible en el Marketplace, con el fin de configurar una «monitorización en la nube». Ahora damos un paso más y ofrecemos una imagen preinstalada, basada en Ubuntu 22.04 (Jammy Jellyfish), con todas las dependencias necesarias ya incluidas. En este escenario solo se utiliza Checkmk Ultimate. Esta tendrá un estado de licencia de «prueba» de 30 días sin restricciones cuando se configure el primer sitio. Una vez que expire el periodo de prueba, Checkmk se puede seguir utilizando como un único sitio con hasta 750 servicios supervisados sin necesidad de una suscripción. Si necesitas supervisar más servicios o se requieren más sitios, necesitarás una clave de licencia.
En general, la configuración es un poco más compleja que, por ejemplo, la imagen Docker; al fin y al cabo, la imagen proporcionada debe cubrir varios escenarios de distribución:
Configuración de un único site en un servidor a varias escalas
Site central en una monitorización distribuida
Site remoto en una monitorización distribuida
Operaciones mixtas que consisten en un sitio de producción y uno o varios sitios para ejecutar pruebas en un host
Por este motivo, la imagen de Azure no incluye un site listo para funcionar, ni una configuración de correo electrónico o de firewall.
En este artículo te guiaremos a través de la configuración completa. Cuando sea útil contar con información adicional, incluiremos enlaces a artículos detallados de nuestro Manual de usuario.
2. Preparación
Además de dimensionar la RAM, el procesador y los discos duros virtuales, también debes pensar en la ubicación donde guardarás las copias de seguridad.
Checkmk es compatible de forma nativa con los almacenes de objetos de Azure, pero las copias de seguridad también se pueden guardar en rutas del sistema de archivos, lo que permite realizar copias de seguridad en montajes SMB o WebDAV o transferencias normales a través de rsync.
2.1. Creación de claves SSH
Dado que Azure no admite actualmente claves ED25519 ni ECDSA, tendrás que crear un par de claves RSA para el primer inicio de sesión en la máquina virtual (VM), cuya clave pública subirás al crear la VM. Como alternativa, puedes dejar que Azure cree el par de claves. En este caso, no olvides descargar la clave privada durante el proceso de pedido.
2.2. Determinación de los puertos necesarios
En una configuración de Checkmk con una sola sede, en la que los hosts también envían datos a la sede de Checkmk en modo push, deben estar accesibles los siguientes puertos del servidor Checkmk:
Desde los hosts en monitorización: Puerto 80/443 (HTTP/HTTPS, durante el registro del agente) y Puerto 8000 (el Receptor del agente, de forma permanente).
Para la gestión a través del navegador y la API-REST: Puerto 80/443 (HTTP/HTTPS)
El uso compartido de estos puertos está predefinido en nuestro archivo «Inbound port rules». Para garantizar la máxima seguridad, debes restringir aún más el acceso en la pestaña «Networking».
Consulta nuestra vista general de todos los puertos utilizados si quieres configurar una monitorización distribuida o, por ejemplo, realizar consultas de estado a través de la interfaz Livestatus.
2.3. Reservar una imagen en el Marketplace
Las siguientes instancias de VM son una recomendación para dimensionar el número de servicios que se van a realizar la monitorización. Al solicitar la instancia, desactiva la opción «burstable».
| Tipo | Cores de CPU | RAM (GB) | SSD (GB) | Servicios de Checkmk |
|---|---|---|---|---|
|
4 |
16 |
32 |
12 000 |
|
8 |
32 |
64 |
30 000 |
|
12 |
48 |
96 |
60 000 |
La base para estos cálculos de dimensionamiento es aproximadamente un 15 % de servicios prestados por agentes especiales y comprobaciones activas, así como 25 o más servicios por host regular entregados a través de un agente en modo push. En determinadas circunstancias, es posible ofrecer un número significativamente mayor de servicios en una monitorización puramente sintética (en la que los datos son entregados principalmente por agentes especiales). Cuando se utilizan agentes en modo pull, es posible que el número de servicios especificado solo se pueda alcanzar mediante una optimización constante.
El dimensionamiento del espacio en disco se basa en la experiencia de entornos típicos de servidores Windows y Linux. Si hay muchos servicios que generan un gran volumen de métricas, puede ser necesario un mayor espacio de almacenamiento.
2.4. Reserva de almacenamiento para copias de seguridad
Debido a los costes de tráfico favorables, recomendamos el uso de Azure Blob Storage. Para calcular el espacio de almacenamiento necesario, lee las notas sobre el formato de datos RRD. Como regla general para calcular una copia de seguridad completa, las bases de datos Round Robin (RRD) habrán alcanzado algo más de un tercio de su capacidad máxima al cabo de 10 días. Esto significa que, pasado este tiempo, conviene revisar de nuevo el tamaño del almacenamiento de copia de seguridad que se ha reservado.
3. Configuración
3.1. Inicio de sesión en la máquina virtual
El inicio de sesión como root está desactivado en las imágenes de AWS/Azure.
En su lugar, se utiliza el usuario ubuntu, que tiene permiso para ejecutar sudo con comandos arbitrarios sin que se le solicite una contraseña.
Si has creado un par de claves independiente para iniciar sesión en la máquina virtual (VM), debes especificar la ruta a su componente privado con el parámetro -i.
Por supuesto, la dirección IP debe personalizarse con aquella desde la que se puede acceder a la máquina virtual (VM) desde una ubicación remota:
Ahora te encontrarás en el indicador de usuario ubuntu.
El indicador real puede contener el nombre del host especificado al crear la máquina virtual o una dirección IP como nombre del host.
Usaremos el nombre del host cloud durante el resto de este artículo:
ubuntu@cloud:~$3.2. Configuración de un site
Un site de Checkmk debe tener un nombre único y también debe ser fácilmente identificable.
Aquí, como en la mayoría de los demás lugares de este manual, usamos mysite como nombre del site.
La contraseña del administrador del site cmkadmin se establece en t0p53cr3t en el ejemplo.
La creación de un site se realiza con la herramienta de administración de Checkmk omd.
La última versión de Checkmk siempre viene preinstalada:
Ahora inicia el site recién creado con
La URL que aparece en la salida del comando anterior (http://cloud/mysite) contiene el nombre del host que utiliza internamente tu máquina virtual de AWS o Azure.
Dado que normalmente no se resuelve externamente, esta URL tiene un uso limitado.
Por lo general, accederás a ella inicialmente utilizando la dirección IP o un nombre del host almacenado en tu propio servidor DNS.
3.3. Almacenamiento de certificados
Para que el sistema Apache pueda escuchar realmente en el puerto HTTPS 443, necesitará certificados válidos. Los certificados autofirmados de Snakeoil Inc. se generan con este fin cuando se inicia la máquina virtual por primera vez. Te recomendamos encarecidamente que los sustituyas lo antes posible por tus propios certificados, que permitan verificar fácilmente la cadena de certificados completa.
Al hacerlo, la configuración de Apache sigue de cerca los estándares de Ubuntu, y las rutas de los certificados modificados deben introducirse en el archivo /etc/apache2/sites-enabled/000-default.conf.
3.4. Configuración de un sistema de correo electrónico
Dado que las rutas para las notificaciones en Checkmk son muchas y pueden variar, no hay un sistema de correo electrónico predeterminado.
Checkmk sin sistema de correo electrónico
También es posible prescindir por completo de un sistema de correo electrónico local si solo quieres habilitar el envío rastreable de correos electrónicos HTML a través de SMTP o confiar en Plugins de notificación para plataformas como Microsoft Teams o Slack.
Ten en cuenta, sin embargo, que en esta configuración no es posible enviar notificaciones masivas.
Agente de transporte de correo (MTA) solo de retransmisión o completo
Por regla general, te interesará configurar un sistema de correo electrónico debido a su mayor flexibilidad. Para entornos más pequeños, el MTA de solo retransmisión Nullmailer ha demostrado funcionar bien.
Para instalaciones más grandes, donde pueden producirse varios cientos de correos electrónicos debido a eventos imprevistos, recomendamos instalar un MTA con todas las funciones, como Postfix.
3.5. Añadir hosts a la monitorización
Localhost en modo pull
En la gran mayoría de los casos, el propio servidor Checkmk debería ser el primer host que añadas a la monitorización.
Para ello, primero debes instalar el agente de Linux en el servidor Checkmk.
Este agente se comunica con el servidor en modo pull.
Si te resulta demasiado engorroso descargar el paquete del agente a través de la interfaz web y luego transferirlo vía scp, puedes instalar el agente en su configuración por defecto («Vanilla») directamente desde el sistema de archivos:
Inmediatamente después de la instalación, el agente Checkmk escucha en el modo Legacy Pull sin cifrar en el puerto 6556. Por lo tanto, realiza sin demora un registro para evitar que terceros no autorizados accedan a la salida del agente:
Hosts en modo push
Si los hosts que se van a supervisar están detrás de un cortafuegos y, por lo tanto, el servidor Checkmk no puede acceder a ellos directamente, el modo push suele ser la ruta de comunicación preferida. Puedes seleccionar el modo push con la opción «Checkmk agent connection mode» en las propiedades del host, en la sección «Agentes de monitorización». Como alternativa, puedes combinar el modo push con paquetes de agentes preconfigurados para el autoregistro y así aumentar aún más la comodidad.
3.6. Actualización de Checkmk
Check la página de descarga con regularidad para ver si hay actualizaciones y descarga el paquete actualizado con el comando wget que aparece allí.
La instalación de una actualización se realiza en dos pasos, debido a que omd puede ejecutar varios sites, cada uno con diferentes versiones de Checkmk, en el mismo servidor.
Instalación de una nueva versión de Checkmk y actualización del site
El primer paso es instalar el paquete; en el siguiente ejemplo, la versión 2.4.0p24:
El siguiente paso es actualizar tu(s) site(s):
Eliminar paquetes que ya no son necesarios
Si tienes varios sitios en el servidor (por ejemplo, uno para uso en producción y otro para probar extensiones), asegúrate de que todos se actualicen:
A través del administrador de paquetes de Ubuntu, puedes desinstalar las versiones de Checkmk que ya no se utilizan:
4. Posprocesamiento
4.1. Configuración de las copias de seguridad
Checkmk cuenta con una práctica función de copia de seguridad, que se configura en «Setup > Maintenance > Backups > Backup targets». Con «Add backup target» añades una ubicación de almacenamiento. Aquí es recomendable seleccionar «Azure Blob Storage» como «Destination» debido a su transferencia de datos rápida y económica.
Además de las credenciales, también debes especificar una ruta de carpeta donde se almacene temporalmente el archivo antes de copiarlo al almacén de objetos.
Esto se puede hacer en /tmp.
Si tu máquina virtual de Azure proporciona una unidad volátil (efímera) en /mnt, aquí también puedes crear un directorio como caché:
Para que el usuario del site pueda escribir en este directorio, debes transferírselo:
Procedimiento para una restauración
La restauración de una copia de seguridad siempre debe realizarse en exactamente la misma versión de Checkmk que se utilizó para crearla. Si se va a utilizar una copia de seguridad para pasar a otro tipo de máquina virtual, a otro proveedor de cloud o de una instalación on-premises a la cloud (o viceversa), actualiza siempre primero a la versión más reciente de Checkmk antes de la copia de seguridad final y la migración.
Los siguientes puntos se aplican a la restauración de una copia de seguridad:
En el sistema de destino, instala exactamente la versión de Checkmk que se utilizó para crear la copia de seguridad.
Crea un sitio de monitorización con
omd createque utilice el mismo nombre de sitio que el sistema de origen.Especifica el destino de la copia de seguridad y sube la clave de copia de seguridad.
Realiza la restauración propiamente dicha.
5. Monitorización de Azure
Checkmk no solo ofrece disponibilidad como imagen de Azure, sino también una monitorización completa de tu infraestructura de Azure. Incluso si Checkmk fuera tu primer o único proyecto de Azure, ya merece la pena supervisar el rendimiento de la máquina virtual, el estado de los almacenes de copias de seguridad y el nivel de costes incurridos.