DOCKER - ZABBIX
📊🐳 Monitorización con Zabbix: servidor en Docker y agentes nativos en Ubuntu Server y Windows 11
En esta práctica se levanta un entorno de monitorización completo con Zabbix, en el que el servidor (server, frontend y base de datos) corre en contenedores Docker, mientras que los equipos a vigilar mantienen el agente Zabbix instalado de forma nativa, tal y como se haría en un entorno de producción real.
El escenario parte de una situación muy habitual: varios equipos con sistemas operativos distintos —un servidor Linux, un puesto Windows, e incluso la propia máquina que aloja la infraestructura de monitorización— funcionando sin que nadie tenga una vista centralizada de su estado. Cada equipo puede estar perfectamente sano, pero si su CPU, memoria o espacio en disco solo se revisan a mano y de forma esporádica, cualquier degradación se detecta tarde. En lugar de depender de la inspección manual máquina por máquina, se despliega un agente Zabbix en cada endpoint, configurado para reportar de forma activa a un servidor centralizado, sin necesidad de abrir puertos de entrada en ninguno de los equipos monitorizados.
🧰 Tecnologías empleadas
Docker y Docker Compose Motor de contenedores que aloja las tres piezas del servidor de Zabbix (base de datos, server y frontend) como servicios independientes, con las credenciales gestionadas en un archivo .env separado en vez de escritas en el propio despliegue.
Zabbix Server y Zabbix Frontend Núcleo de la plataforma de monitorización: el server procesa la telemetría entrante y evalúa los triggers, mientras que el frontend (servido con Nginx) permite consultar los datos, crear hosts y definir plantillas desde el navegador.
MySQL Motor de base de datos donde Zabbix persiste su configuración, su histórico de métricas y sus eventos, desplegado también como contenedor con su propio volumen de datos.
Zabbix Agent 2 Agente nativo instalado en cada endpoint a monitorizar. A diferencia del servidor, el agente no vive en un contenedor: se instala directamente sobre el sistema operativo de cada máquina, igual que ocurriría en una instalación real sobre servidores físicos o virtuales.
Checks activos Modelo de comunicación en el que es el propio agente quien inicia la conexión hacia el servidor para enviar sus datos, en lugar de esperar a que el servidor le pregunte. Esto permite centralizar toda la superficie de firewall en un único punto (el servidor), sin necesidad de abrir puertos de entrada en ninguno de los equipos monitorizados.
🎯 Objetivos de la práctica
El objetivo principal es demostrar que un servidor de monitorización en contenedores puede convivir con agentes nativos en equipos reales de distintos sistemas operativos, sin que la naturaleza containerizada del servidor suponga ninguna limitación a la hora de vigilar infraestructura tradicional.
De forma más concreta, se busca levantar el stack de Zabbix con Docker Compose de forma reproducible, instalar y dar de alta el agente en tres endpoints distintos —el propio host que aloja Docker, un servidor Ubuntu y un equipo Windows 11—, configurar la comunicación en modo activo para minimizar la superficie expuesta en cada endpoint, y verificar de extremo a extremo que la telemetría de los tres equipos llega de forma continua al mismo panel.
🧩 Desarrollo de la práctica
Levantar el stack de Zabbix con Docker Se define el despliegue completo (base de datos, servidor y frontend) en un único archivo de Compose, con las contraseñas aisladas en un .env independiente, y se valida que los tres servicios arrancan correctamente y en el orden adecuado.
Primer acceso al frontend Se accede al panel web recién desplegado y se confirma que la base de datos ya quedó configurada automáticamente a partir de las variables de entorno, sin necesidad de completar ningún asistente de configuración manual.
Agente en Ubuntu Server Se instala el agente Zabbix nativo en el primer endpoint Linux, configurado para reportar en modo activo al servidor, y se da de alta como host en el frontend con su plantilla correspondiente.
Agente en el propio host Docker Se repite el proceso sobre la máquina que aloja el propio stack de Zabbix, tratándola como un endpoint más a monitorizar —una comprobación habitual en cualquier despliegue real, donde la infraestructura de monitorización también necesita ser vigilada.
Agente en Windows 11 Se instala el agente en el tercer endpoint, esta vez sobre un sistema operativo distinto, confirmando que el mismo modelo de checks activos funciona igual de bien independientemente del sistema operativo del agente.
Verificación de extremo a extremo Se comprueba en el propio frontend que los tres hosts —Linux, Windows y el servidor Docker— reportan telemetría real y actualizada: uso de CPU, memoria disponible y espacio en disco, entre otras métricas incluidas de fábrica en las plantillas estándar.
🔍 ¿Por qué es importante esta práctica?
Un servidor de monitorización que solo puede vigilar equipos idénticos entre sí, o que exige que la infraestructura completa viva en el mismo formato (todo en contenedores, o todo en máquinas físicas), tiene un valor limitado en un entorno real, donde la heterogeneidad es la norma: servidores Linux, puestos Windows, y ahora también infraestructura containerizada, conviviendo todos en la misma organización.
Además, el modelo de checks activos tiene una implicación de seguridad directa: al ser el agente quien inicia la conexión, ningún endpoint necesita exponer un puerto de entrada, lo que reduce la superficie de ataque de cada máquina monitorizada a cero puertos adicionales. Esto es especialmente relevante cuando se piensa en escalar de tres equipos a varias decenas: toda la gestión de firewall queda centralizada en un único punto, el servidor, en lugar de multiplicarse por cada endpoint nuevo.
✅ Resultados esperados
Al finalizar la práctica, el servidor Zabbix desplegado en Docker recibe telemetría continua y actualizada de tres endpoints de naturaleza completamente distinta —un servidor Linux, un puesto Windows y la propia máquina que aloja la infraestructura de monitorización—, todos ellos visibles y consultables desde el mismo panel centralizado, sin que ninguno haya necesitado abrir un puerto de entrada para lograrlo.
🏢 Propuesta empresarial
Clockwork Computer necesita dejar de depender de la revisión manual del estado de sus servidores y puestos de trabajo. Hasta ahora, comprobar si un equipo tenía la CPU saturada, la memoria agotada o el disco a punto de llenarse dependía de conectarse a cada máquina de forma individual, sin ningún mecanismo de alerta centralizada ni de correlación entre equipos.
El departamento de IT ha decidido desplegar Zabbix como plataforma de monitorización centralizada, aprovechando Docker para el propio servidor de Zabbix y manteniendo agentes nativos en cada equipo real de la organización, de forma que la vigilancia de la infraestructura pase a gestionarse desde un único punto.
📌 Escenario propuesto
Clockwork Computer dispone de un servidor Ubuntu en producción, varios puestos de trabajo con Windows 11, y ha decidido levantar su nueva plataforma de monitorización sobre Docker en un servidor dedicado. El objetivo es que ese mismo servidor Docker, además de alojar Zabbix, sea también uno de los equipos monitorizados, y que el modelo se pueda escalar después a toda la flota sin rediseñar nada.
🎯 Requisitos técnicos solicitados por la empresa
La empresa solicita implementar las siguientes tareas:
Levantar el servidor de Zabbix (base de datos, server y frontend) en Docker, con las credenciales gestionadas de forma segura y separadas del propio despliegue. Instalar el agente Zabbix nativo en un servidor Ubuntu de producción y darlo de alta en el frontend. Instalar el agente nativo también en el propio servidor que aloja Docker, tratándolo como un endpoint más. Instalar el agente en un equipo Windows 11 y confirmar que el mismo modelo de configuración funciona igual que en Linux. Configurar la comunicación entre agentes y servidor en modo activo, para no depender de abrir puertos de entrada en ningún equipo monitorizado. Verificar de extremo a extremo que los tres equipos reportan telemetría real y consultable desde el mismo panel.
🔐 Justificación técnica y de seguridad
Clockwork Computer necesita ampliar su capacidad de supervisión de infraestructura sin multiplicar la complejidad de gestión de firewall por cada equipo nuevo que se sume. El modelo de checks activos resuelve justo ese problema: es el agente quien se conecta hacia el servidor, nunca al revés, de forma que añadir un endpoint nuevo a la plataforma no implica abrir ningún puerto adicional en esa máquina.
Separar las credenciales de la base de datos en un archivo de variables de entorno independiente, en lugar de dejarlas escritas en el propio despliegue, reduce el riesgo de que esa información sensible acabe expuesta al compartir o versionar la configuración del servidor.
🧪 Validación esperada
Al finalizar la práctica, Clockwork Computer deberá comprobar que los tres equipos —el servidor Ubuntu, el puesto Windows 11 y el propio servidor Docker— aparecen en el panel de Zabbix reportando métricas reales y actualizadas de forma continua, sin que en ningún momento haya sido necesario abrir un puerto de entrada en ellos para lograrlo.
✅ Resultado empresarial esperado
Como resultado final, Clockwork Computer dispondrá de una plataforma de monitorización centralizada capaz de vigilar equipos de distinta naturaleza —servidores Linux, puestos Windows e infraestructura containerizada— desde un único panel, con un modelo de comunicación que no exige exponer puertos adicionales en cada endpoint nuevo. La vigilancia de la infraestructura dejará de depender de la revisión manual equipo por equipo, quedando preparada para escalar a toda la flota de la organización sin cambiar el modelo ya validado en esta práctica.
Comentarios
Publicar un comentario