 |
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 usuario de Checkmk desde hace tiempo, como si nos has encontrado recientemente con la disponibilidad de imágenes preparadas en el Marketplace de Microsoft Azure, en este artículo encontrarás todos los recursos necesarios para configurar la imagen VM preparada en una monitorización que se adapte a tus necesidades.
Si eres nuevo en Checkmk, te recomendamos que leas nuestra Guía para principiantes como preparación. Las imágenes VM preconfiguradas pueden acortar muchas tareas durante una instalación, pero algunos conocimientos de conceptos fundamentales, como los sites, te ayudarán durante el proceso de configuración.
1.1. 1.1. Conceptos básicos
Si eres usuario de Azure, siempre has tenido la opción de añadir Checkmk a una imagen existente de Ubuntu disponible en el Marketplace, para configurar una "monitorización en la nube". Checkmk 2.2.0 va un paso más allá y proporciona una imagen preinstalada basada en Ubuntu 22.04 (Jammy Jellyfish) con todas las dependencias necesarias ya incluidas. En este caso sólo se utiliza Checkmk Cloud, que estará en un estado de licencia "Trial" de 30 días sin restricciones cuando se configure el primer site. Una vez finalizado el periodo de prueba, Checkmk puede seguir utilizándose como site único con hasta 750 servicios monitorizados sin necesidad de suscripción. Si es necesario monitorizar más servicios o más sites, necesitarás una clave de licencia.
En general, la configuración es un poco más complicada que, por ejemplo, la imagen Docker, después de todo, la imagen proporcionada debe cubrir varios escenarios de despliegue:
Configuración de un solo site en un servidor a varias escalas
site central en una monitorización distribuida
site remoto en una monitorización distribuida
Operaciones mixtas consistentes en un site de producción y site(s) para ejecutar pruebas en un host
Por este motivo, la imagen de Azure no incluye un site listo para funcionar, un correo electrónico ni una configuración de cortafuegos.
En este artículo te guiaremos a través de la configuración completa. En los casos en que resulte útil disponer de información de fondo adicional, enlazamos a artículos detallados de nuestro Manual de usuario.
2. Preparación
Además del dimensionamiento de la RAM, el procesador y los discos duros virtuales, también debes pensar en la ubicación para el almacenamiento de las copias de seguridad. Checkmk admite de forma nativa los almacenes de objetos de Azure, pero las copias de seguridad también pueden almacenarse en rutas del sistema de archivos, lo que permite realizar copias de seguridad en montajes SMB o WebDAV o transferencias regulares a través de rsync.
2.1. Crear claves SSH
Como Azure no admite actualmente claves ED25519 o ECDSA, crearás un par de claves RSA para el primer inicio de sesión en la máquina virtual, 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. Determinar los puertos necesarios
En una configuración Checkmk con un único site, en la que los hosts también envían datos al site Checkmk en modo push, los siguientes puertos del servidor Checkmk deben ser accesibles:
Desde los hosts en monitorización: Puerto 80/443 (HTTP/HTTPS, durante el registro del agente) y Puerto 8000 (el Receptor del agente, permanentemente).
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 Inbound port rules. Para la mejor seguridad posible, 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 Mercado
Las siguientes instancias VM son una recomendación para dimensionar el número de servicios a monitorizar. Al pedir la instancia, desactiva la opción burstable.
| Tipo | Núcleos CPU | RAM (GB) | SSD (GB) | Servicios 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 por agentes especiales y checks activos, así como 25 o más servicios por host regular suministrados a través de un agente en modo push. En determinadas circunstancias, es posible un número significativamente mayor de servicios en una monitorización puramente sintética (en la que los datos son suministrados principalmente por agentes especiales). Cuando se utilizan agentes en modo pull, el número especificado de servicios sólo puede alcanzarse mediante una optimización coherente.
El dimensionamiento del espacio de disco duro se basa en la experiencia de entornos típicos de servidores Windows y Linux. Si hay muchos servicios que producen un gran volumen de métricas, puede ser necesario un mayor espacio de almacenamiento.
2.4. Reserva de almacenamiento de copias de seguridad
Debido a los costes de tráfico favorables, aconsejamos 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 habrán alcanzado algo más de un tercio de su capacidad máxima al cabo de 10 días. Esto significa que, transcurrido este tiempo, tiene sentido volver a revisar el tamaño del almacenamiento de copia de seguridad que se ha reservado.
3. Configurar
3.1. Inicio de sesión en la máquina virtual
El inicio de sesión como usuario root está desactivado en las imágenes de AWS/Azure. En su lugar, se emplea el usuario ubuntu, que tiene permiso para ejecutar sudo con comandos arbitrarios sin solicitud de contraseña. Si has creado un par de claves independiente para el inicio de sesión en la máquina virtual, debes especificar la ruta a su componente privado con el parámetro -i. Por supuesto, la dirección IP debe personalizarse para que sea aquella con la que se puede acceder a la máquina virtual desde una ubicación remota:
user@host:~$ ssh -i /path/to/id_file.priv ubuntu@192.0.2.123Ahora te encontrarás en el indicador de usuario ubuntu. El indicador actual puede contener el nombre del host especificado cuando se creó la máquina virtual o una dirección IP como nombre del host. Utilizaremos el nombre del host cloud en el resto de este artículo:
ubuntu@cloud:~$3.2. Configurar un site
Un sitio 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, utilizamos mysite como nombre del sitio.
La creación de un site se realiza con la herramienta de administración de Checkmk. omdLa última versión de Checkmk está siempre preinstalada:
ubuntu@cloud:~$ sudo omd create mysite
Adding /opt/omd/sites/mysite/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...
Starting full compilation for all hosts Creating global helper config...OK
Creating cmc protobuf configuration...OK
Executing post-create script "01_create-sample-config.py"...OK
Restarting Apache...OK
Created new site mysite with version 2.2.0p1.cce.
The site can be started with omd start mysite.
The default web UI is available at http://cloud/mysite/
The admin user for the web applications is cmkadmin with password: UbWeec9QuazIf
For command line administration of the site, log in with 'omd su mysite'.
After logging in, you can change the password for cmkadmin with 'cmk-passwd cmkadmin'.Ahora inicia el site recién creado con
ubuntu@cloud:~$ sudo omd start mysiteLa URL de la salida del comando que se muestra arriba (http://cloud/mysite) contiene el nombre del host utilizado internamente por tu máquina virtual de AWS o Azure. Dado que normalmente no se resuelve externamente, esta URL es de uso limitado. Normalmente, accederás inicialmente utilizando la dirección IP o un nombre del host almacenado en tu propio servidor DNS.
3.3. Almacenar 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 las normas de Ubuntu, y las rutas modificadas de los certificados deben introducirse en el archivo /etc/apache2/sites-enabled/000-default.conf.
3.4. Configurar un sistema de correo electrónico
Puesto que las rutas para las notificaciones en Checkmk son muchas y pueden variar, no se ha predefinido un sistema de correo electrónico por defecto.
Checkmk sin sistema de correo electrónico
También es posible prescindir por completo de un sistema de correo electrónico local si sólo quieres habilitar la entrega rastreable de correos electrónicos HTML a través de SMTP o confiar en Plugin de notificación para plataformas como Microsoft Teams o Slack.
Ten en cuenta, sin embargo, que las notificaciones masivas no son posibles en esta configuración.
Sólo retransmisión o agente de transporte de correo (MTA) completo
Por regla general, querrás configurar un sistema de correo electrónico por su mayor flexibilidad. Para entornos más pequeños, se ha demostrado que el MTA de sólo retransmisión Nullmailer funciona bien.
Para instalaciones más grandes, donde los eventos imprevistos pueden dar lugar a varios cientos de correos electrónicos, recomendamos instalar un MTA con todas las funciones, como Postfix.
3.5. Añadir hosts a una monitorización
Localhost en modo pull
En la gran mayoría de los casos, el propio servidor Checkmk debe ser el primer host que añadas a la monitorización. Para ello, primero debes instalar el agente Linux en el servidor Checkmk. Este agente se comunica con el servidor en el modo pull. Si la descarga del paquete del agente a través de la interfaz web seguida de una transferencia a través de scp te parece demasiado engorrosa, puedes instalar el agente en su configuración por defecto ("Vanilla") directamente desde el sistema de archivos:
ubuntu@cloud:~$ sudo apt install $(sudo find /opt/omd/versions/ -name 'check-mk-agent_*.deb' | tail -n1)Inmediatamente después de la instalación, el agente Checkmk escucha en modo Legacy Pull no cifrado en el puerto 6556. Por tanto, realiza inmediatamente un registro para evitar que terceros no autorizados accedan a la salida del agente:
ubuntu@cloud:~$ sudo cmk-agent-ctl register --hostname localhost --server localhost --site mysite --user cmkadminHost en modo push
Si los hosts que se van a monitorizar están detrás de un cortafuegos y, por 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, a fin de aumentar aún más la comodidad.
3.6. Actualizar Checkmk
Comprueba regularmente si hay actualizaciones en la página de descarga y descarga el paquete actualizado con el comando wget que allí se muestra.
La instalación de una actualización se realiza en dos pasos, lo que se debe a que omd puede ejecutar varios sites, cada uno con versiones diferentes de Checkmk, en el mismo servidor.
Instalar una nueva versión de Checkmk y actualizar el site
El primer paso es instalar el paquete, en el siguiente ejemplo la versión 2.2.0p2:
ubuntu@cloud:~$ sudo apt install ./check-mk-cloud-2.2.0p2_0.jammy_amd64.debEl siguiente paso es actualizar tu site o sites:
ubuntu@cloud:~$ sudo omd stop mysite
ubuntu@cloud:~$ sudo omd update mysite
ubuntu@cloud:~$ sudo omd start mysiteEliminar los paquetes que ya no son necesarios
Si tienes varios sites en el servidor (por ejemplo, uno para producción y otro para probar extensiones), asegúrate de que todos ellos están actualizados:
ubuntu@cloud:~$ omd sites
SITE VERSION COMMENTS
mysite 2.2.0p2.cce default version
mytestsite 2.2.0p2.cce default versionA través del administrador de paquetes de Ubuntu puedes desinstalar las versiones de Checkmk que ya no utilices:
ubuntu@cloud:~$ sudo apt purge check-mk-cloud-2.2.0p14. Postprocesado
4.1. Configurar las copias de seguridad
Checkmk dispone de una cómoda 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 aconsejable seleccionar Azure Blob Storage como Destination por su transferencia de datos rápida y barata.
Además de las credenciales, también debes especificar una ruta de carpeta en la que se almacene temporalmente el archivo antes de copiarlo en el almacén de objetos, que puede estar en /tmp. Si tu VM de Azure proporciona una unidad volátil (efímera ) en /mnt, aquí también puedes crear un directorio como caché:
ubuntu@cloud:~$ sudo mkdir -p /mnt/backup/mysitePara que el usuario del site pueda escribir en este directorio, debes transferírselo:
ubuntu@cloud:~$ sudo chown mysite:mysite /mnt/backup/mysiteProcedimiento para una restauración
La restauración de una copia de seguridad debe realizarse siempre exactamente en la misma versión de Checkmk que se utilizó para crearla. Si se va a utilizar una copia de seguridad para migrar 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 al nivel de parche más alto disponible de Checkmk antes de realizar 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 site de monitorización con
omd createque utilice el mismo nombre de site que el sistema de origen.Especifica el destino de la copia de seguridad y carga la clave de la copia de seguridad.
Realiza la restauración propiamente dicha.
5. Monitorización de Azure
Checkmk no sólo proporciona disponibilidad como imagen de Azure, sino también una monitorización exhaustiva de tu infraestructura de Azure. Aunque Checkmk sea tu primer o único proyecto de Azure, ya merece la pena monitorizar el rendimiento de la máquina virtual, el estado de las cajas fuertes y el nivel de costes incurridos.