Mi mujer fue más rápida que mi monitorización: Zabbix en contenedores vigila ahora mi red doméstica

En resumen: hace algo más de dos semanas mi mujer llegó a casa y no tenía wifi. El punto de acceso de la planta baja ni siquiera respondía a un ping. Desenchufar, volver a enchufar, y desde entonces funciona. Nadie más se había dado cuenta, tampoco mi monitorización. Ahora, en mi servidor NAS, un Zabbix 7.0 LTS corre en cuatro contenedores Podman rootless y me envía un correo en cuanto un componente de la red doméstica deja de responder. Este artículo describe el montaje, lo que tuve que configurar además, dónde se atascó y dónde está cada cosa en la interfaz web.

📶 Cómo empezó todo

Mi mujer llegó a casa, su móvil no mostraba wifi y – comprensiblemente – no estaba nada contenta. Pude confirmarlo enseguida: el punto de acceso de la planta baja no era accesible, ni por su interfaz web ni por ping. Desenchufar, esperar unos segundos, volver a enchufar. Desde hace unos 14 días funciona sin ningún problema. Por qué falló, sigo sin saberlo. Es uno de esos fenómenos que ocurren una vez y se niegan a repetirse.

Lo que me dio mucho más que pensar fue otra cosa: ¿por qué me enteré por mi mujer y no por mi monitorización? La respuesta es sencilla. Prometheus y Grafana vigilan mis servidores, y una comprobación de disponibilidad verifica cada cinco minutos desde fuera que el blog y Nextcloud respondan. Nadie vigilaba las cajitas de la red doméstica – router, repetidores, switch, base del teléfono, inversor solar. No tienen agente; lo único que se puede hacer es preguntarles si responden.

Lo que queda: una monitorización cubre exactamente aquello para lo que se construyó. Los huecos suelen estar en los dispositivos discretos que simplemente funcionan – hasta que dejan de hacerlo.

🔭 ¿Qué es Zabbix?

Zabbix es un software de monitorización de código abierto: vigila de forma continua servidores, equipos de red, aplicaciones y servicios. Alexei Vladishev lo empezó en 2001 como herramienta interna, y la versión 1.0 salió en 2004. Hoy lo desarrolla la empresa Zabbix SIA en Riga, Letonia. El software es completamente libre – no existe una «edición enterprise» de pago que se guarde funciones; la empresa vive del soporte, la formación y las certificaciones. Hasta la versión 6.4, Zabbix estaba bajo GPLv2; desde la 7.0, bajo AGPLv3. Cada año y medio aparece una versión LTS con cinco años de mantenimiento.

Por qué es conocido Zabbix:

• Todo en uno. Recogida de datos, almacenamiento, reglas de alerta, notificaciones, paneles, mapas e informes vienen en un solo producto con una sola interfaz web. Con Prometheus y Grafana son varias herramientas que uno mismo tiene que combinar.
• Con y sin agente. El agente de Zabbix (hoy sobre todo el Agent 2, escrito en Go y ampliable con plugins) mide sistemas operativos y aplicaciones desde dentro. Para los dispositivos en los que no se puede instalar nada existen comprobaciones sin agente: ping, puertos TCP, HTTP, SNMP, IPMI, SSH y más.
• Redes y SNMP. Zabbix está especialmente extendido cuando se trata de switches, routers, cortafuegos, SAI e impresoras. Hay plantillas listas para innumerables dispositivos.
• Plantillas y descubrimiento automático. Una plantilla agrupa comprobaciones, alertas y gráficas. Con el descubrimiento de bajo nivel (low-level discovery), Zabbix averigua por sí mismo qué sistemas de archivos, tarjetas de red o discos tiene un dispositivo y crea las comprobaciones correspondientes.
• Entornos grandes. Mediante proxies, la monitorización se reparte entre muchas sedes; Zabbix está pensado para decenas de miles de dispositivos.
• Una API completa. Todo lo que hace la interfaz también funciona por JSON-RPC – toda la configuración de este artículo la creé con un script contra la API.

Dónde se encuentra Zabbix: en proveedores de internet y operadoras de telecomunicaciones, en centros de datos, bancos, administraciones públicas y universidades, en muchos departamentos de TI de empresas medianas – allí donde hay que vigilar desde un solo lugar un paisaje variado de servidores, equipos de red y dispositivos especiales.

La otra cara: Zabbix es potente, y su interfaz lo deja ver. La configuración vive en la base de datos y no en archivos de texto, lo que hace la «configuración como código» más difícil que con Prometheus. Y el vocabulario – host, item, trigger, template, action – hay que interiorizarlo una vez antes de que todo tenga sentido.

Por cierto: justo después de la instalación, el mapa del panel mostraba Riga – es donde tiene su sede Zabbix.

Lo que queda: Zabbix es la navaja suiza de las herramientas de monitorización. Saca todo su potencial con muchos dispositivos distintos que no tienen agente propio.

🎯 El objetivo y por qué Zabbix

El requisito era deliberadamente pequeño: un correo cuando un componente interno deja de responder. Para dispositivos sin agente, eso significa un ping donde el dispositivo responde al ping, y una prueba de conexión TCP a un puerto como el 80 o el 443 donde tiene interfaz web.

A eso se sumó un segundo deseo: también quiero enterarme cuando el propio internet se cae – y recibir entonces un único correo «internet no accesible» en lugar de cinco alertas sueltas, una por cada servidor externo.

Un pequeño script podría hacerlo. Aun así elegí Zabbix, por dos razones. Primero, Zabbix trae exactamente estas comprobaciones sin agente, además de historial, gráficas, dependencias entre alertas y envío de correo. Segundo, por interés profesional quiero ganar más experiencia práctica con Zabbix – montarlo yo, configurarlo yo, equivocarme yo, en lugar de solo leer sobre él. La red doméstica es un campo de prácticas ideal: lo bastante real para tener sentido y lo bastante pequeña para que un error no duela.

Elegí Zabbix 7.0 LTS (7.0.32). La versión 8.0.0 acababa de salir, pero no necesito estrenar una versión punto cero mientras aprendo la herramienta.

Lo que queda: para aprender una herramienta nueva, un problema real y pequeño vale más que una demo. Y una versión LTS quita una incógnita de la ecuación.

🧱 El montaje: cuatro contenedores, sin root

Zabbix corre en HP3, mi servidor NAS con Debian y ZFS. Está encendido día y noche de todos modos y tiene recursos de sobra (4 núcleos, 32 GB de RAM, más de un tercio libre). El montaje consta de cuatro contenedores:

Las decisiones clave detrás:

• Podman rootless en lugar de Docker como root. Todo corre con mi usuario normal; un error en un contenedor no aterriza como root en el NAS.
• Quadlet en lugar de Compose. Cada contenedor es un pequeño archivo .container en ~/.config/containers/systemd/. Podman los convierte en servicios systemd normales – con dependencias, reinicio tras un fallo y arranque al iniciar el sistema. Para que los servicios de usuario arranquen sin que nadie inicie sesión, hace falta una vez loginctl enable-linger.
• Red del host en lugar de NAT. Con Network=host, los pings y las pruebas TCP van directamente a la red doméstica, sin la traducción de direcciones de Podman. PostgreSQL, en cambio, escucha explícitamente solo en 127.0.0.1.
• Límites fijos de memoria y CPU, para que Zabbix nunca estorbe al NAS. En la práctica, los cuatro contenedores juntos usan unos 180 MB.
• Nada de contraseñas en archivos. La contraseña de la base de datos es un secreto de Podman que se entrega a los contenedores como archivo, y la contraseña del administrador de la interfaz la cambié por la API justo después del primer arranque.

Este es el archivo del servidor:

[Unit]
Description=Zabbix server
Requires=zabbix-db.service
After=zabbix-db.service

[Container]
ContainerName=zabbix-server
Image=docker.io/zabbix/zabbix-server-pgsql:alpine-7.0.32
Network=host
Environment=DB_SERVER_HOST=127.0.0.1 POSTGRES_USER=zabbix POSTGRES_DB=zabbix
Environment=POSTGRES_PASSWORD_FILE=/run/secrets/zabbix-db-pw
Secret=zabbix-db-pw
AddCapability=NET_RAW
PodmanArgs=--memory=768m --cpus=1

[Service]
Restart=always

[Install]
WantedBy=default.target

Lo que queda: Quadlet convierte los contenedores en servicios systemd corrientes. No hace falta un orquestador, y systemctl --user status lo muestra todo en un mismo sitio.

💾 ¿Dónde va la base de datos?

Una pregunta evidente era si la base de datos debía ir en el SSD del sistema o en el pool ZFS, pensado en realidad para las carpetas compartidas. Elegí el pool. HP3 solo tiene SSD, también los tres discos del RAIDZ1 – así que la velocidad no es un argumento en contra. A cambio, la base de datos sobrevive allí a la pérdida de un disco, ZFS detecta bloques dañados mediante sumas de verificación, y el directorio está en mi dataset personal, que el PC de copias copia por la noche de todos modos. El SSD del sistema tiene más de 400 GB libres, pero es un único disco y no está en la copia de seguridad.

Los volúmenes son modestos: tras el primer día, la base de datos no llega a 100 MB. Un dataset ZFS propio con un tamaño de bloque ajustado a PostgreSQL sería más limpio, pero requiere root – no compensa a esta escala.

Lo que queda: el disco más rápido no es automáticamente el adecuado. Para una base de datos, la redundancia y la copia de seguridad cuentan más que el último tanto por ciento de rendimiento.

📡 Qué se vigila

En Zabbix, la red está repartida en dos grupos de hosts: LAN para los dispositivos de casa y Extern para mis servidores en el centro de datos.

En la LAN, Zabbix comprueba cada minuto:

• Ping para el router, los tres repetidores wifi, el switch, la base del teléfono, la ventilación, el inversor solar y dos enchufes inteligentes. Para ello Zabbix trae la plantilla ICMP Ping. Marca un dispositivo como no accesible cuando tres pings seguidos quedan sin respuesta – es decir, al cabo de unos tres minutos. Un único ping perdido no dispara ninguna alerta.
• Un puerto TCP además, allí donde hay interfaz web: 443 en el router y el switch, 80 en la ventilación y el inversor. La clave es net.tcp.service[tcp,<ip>,<port>], y esta alerta también salta solo tras tres intentos fallidos.
• Solo TCP 443 para los tres controladores de gestión remota de los servidores (BMC). Están en la misma red, pero lo que importa es que responda su interfaz.

Un detalle que sin Zabbix no tendría: la alerta de puerto depende de la alerta de ping. Si un dispositivo cae por completo, recibo un correo («no accesible por ping ICMP») y no dos. La alerta de puerto solo aparece cuando el dispositivo responde al ping pero su interfaz web no.

El propio HP3 lo mide el Agent 2: CPU, RAM, carga, swap, procesos, cada tarjeta de red, los datasets ZFS y la entrada/salida de los cuatro SSD. La plantilla Linux by Zabbix agent lo cubre todo, y Zabbix crea las gráficas por sí solo.

Los servidores externos – el blog y dos instancias de Nextcloud – se comprueban mediante escenarios web: una petición cada dos minutos, esperando HTTP 200 y un contenido concreto. En el blog es el final de la página de inicio; en Nextcloud, status.php debe contener "maintenance":false; en Collabora debe responder el descubrimiento WOPI. Además, el agente lee los certificados TLS cada seis horas y avisa 14 días antes de que caduquen.

El propio internet lo comprueba un host aparte llamado «Internet»: cada minuto hace ping a dos servidores DNS públicos independientes (1.1.1.1 y 9.9.9.9) y consulta https://www.google.com/generate_204, una dirección pensada precisamente para este tipo de pruebas de conectividad que solo devuelve «204 No Content». La alerta «internet no accesible» solo salta cuando ambos servidores callan tres veces seguidas – un fallo en un único proveedor no es una caída de internet. Las alertas de los servidores externos dependen de ella: si internet se cae, llega exactamente un correo.

Deliberadamente no compruebo SSH ni puertos abiertos en esos servidores. Una simple conexión al puerto 22 sin iniciar sesión acaba en el registro de sshd, y fail2ban puede convertirla en un bloqueo de mi propia IP de casa. Una prueba rápida de varios puertos activaría el bloqueo antiescaneo del cortafuegos. Una petición HTTPS cada dos minutos, en cambio, es un visitante de lo más normal.

Lo que queda: las buenas alertas son austeras. Tres intentos fallidos en lugar de uno y dependencias entre alertas hacen que un correo signifique algo de verdad.

🐛 Las trampas

No hay montaje sin sorpresas. Estas fueron las instructivas:

1. Al principio el ping no funcionaba en absoluto. Cada comprobación acababa con sh: /usr/sbin/fping: Operation not permitted. En la imagen del servidor, fping lleva la capacidad de archivo cap_net_raw=ep. Si esa capacidad falta en el contenedor, el núcleo se niega ya a arrancar el programa – no solo el ping. La solución fue una línea: AddCapability=NET_RAW en el archivo Quadlet del servidor.
2. Un signo de exclamación en el nombre de host. Zabbix rechaza «FRITZ!Box» como nombre de host. El nombre técnico solo admite letras, cifras, espacios, puntos, guiones bajos y guiones. Por eso Zabbix separa el nombre técnico del visible name – el segundo es el que se muestra en todas partes.
3. Una IP «libre» no lo estaba. Para la prueba de correo quería simular una caída y apunté un dispositivo de prueba a una dirección que no había respondido en mi escaneo de ping. Zabbix informó entonces de un 66 % de pérdida de paquetes – sí había algo, solo que respondía de forma irregular. Desde entonces, para pruebas uso una dirección del rango de documentación (192.0.2.1, RFC 5737), que nunca responde.
4. Un Zabbix recién instalado no envía correos. La acción que comunica los problemas a los administradores viene desactivada de fábrica, y el usuario administrador no tiene dirección de correo. Sin esos dos pasos todo se ve verde y aun así nunca llega ninguna alerta.
5. El agente en un contenedor no ve automáticamente el host. CPU, RAM, red y estadísticas de disco vienen igualmente del núcleo del host. Para los sistemas de archivos monté la raíz del host en solo lectura bajo /hostfs y, con una macro, solo admití los sistemas de archivos reales; si no, aparecen los montajes overlay internos de Podman. El agente solo encontró los discos cuando los archivos de dispositivo /dev/sda a /dev/sdd fueron visibles en el contenedor – aun así, solo lee /proc/diskstats.
6. Zona horaria y formato de hora. La interfaz estaba en UTC y mostraba «03:26 PM». En Administration → General → GUI ajusté Europe/Berlin y el formato de 24 horas.

Lo que queda: ninguno de los fallos estaba en Zabbix. Estaban en las juntas: contenedor y núcleo, datos de prueba y realidad, valores por defecto y expectativas.

✉️ La prueba: una caída escenificada

Una configuración de correo solo está demostrada cuando llega un correo. Zabbix usa la misma cuenta SMTP con la que HP3 ya envía sus correos de estado (puerto 587, STARTTLS). Para la prueba apunté un dispositivo a la dirección de documentación y esperé:

• A los tres minutos aproximadamente llegó el correo «Problem: ICMP Ping: Unavailable by ICMP ping».
• Después de volver a apuntar la dirección a un dispositivo real, llegó «Resolved in 1m 0s».

Luego borré el dispositivo de prueba. Para las capturas de este artículo volví a escenificar la caída, con las notificaciones apagadas – por eso el punto de acceso caído se llama «WLAN-AP EG» (planta baja) en las imágenes.

Lo que queda: una alerta nunca probada es una suposición. Una caída provocada a propósito cuesta cinco minutos y demuestra toda la cadena, del ping al buzón.

🧭 Un recorrido por la interfaz

Zabbix abruma al principio: la navegación tiene más de una docena de entradas principales con muchas subpáginas. Para el día a día en una red doméstica, sin embargo, bastan unos pocos sitios. Esta tabla es mi botiquín de primeros auxilios – debajo, cada entrada explica qué se encuentra allí.

Dashboards → Global view: la vista general

La página de inicio muestra la disponibilidad de todos los hosts, los problemas por gravedad, los problemas actuales y un mapa. El recuadro «Host availability» confunde al principio: los dispositivos sin agente aparecen en gris como «Unknown». No es un error – simplemente no tienen agente; su estado está en las comprobaciones de ping y de puerto. El mapa (Geomap) sitúa los dispositivos en el lugar indicado en su inventario; puse la localidad en lugar de una dirección exacta.

Monitoring → Problems: lo que está roto ahora

Es la página más importante. Aquí aparece cada problema abierto con su inicio, duración y gravedad. Con Update se puede confirmar un problema («me encargo yo») y dejar un comentario. El filtro History muestra también los problemas resueltos – útil para averiguar más tarde cuándo desapareció por última vez el punto de acceso.

Monitoring → Hosts y Latest data: el estado de cada dispositivo

Monitoring → Hosts (imagen más arriba, en «Qué se vigila») lista cada dispositivo con enlaces a sus últimos valores, problemas, gráficas y escenarios web. Latest data muestra los valores en bruto: si volvió el último ping, cuánto tardó, si un puerto estaba abierto. Cada valor enlaza con una gráfica.

Monitoring → Hosts → Web: los servidores externos

Zabbix 7.0 ya no tiene una entrada de menú propia: en Monitoring → Hosts se hace clic en el enlace Web junto a un equipo. Ahí están los escenarios web del blog, Nextcloud y Collabora, con la hora y el resultado de la última ejecución. Un clic en el nombre muestra la evolución del tiempo de respuesta y de la velocidad de descarga. Si un escenario falla, se ve qué paso falló y con qué error.

Data collection → Hosts: añadir un dispositivo nuevo

Los dispositivos nuevos se añaden en Data collection → Hosts → Create host. Para un dispositivo que solo necesita ping, bastan cinco campos:

1. Host name – el nombre técnico, solo caracteres sencillos.
2. Visible name – el nombre que se muestra en todas partes.
3. Templates – elegir ICMP Ping.
4. Host groups – por ejemplo LAN.
5. Interfaces – una interfaz con la dirección IP del dispositivo. El tipo da igual para el ping; Zabbix toma la dirección de la interfaz.

Guardar y listo – los primeros valores llegan en menos de un minuto. Para comprobar también un puerto, se añade en Items del host un elemento de tipo Simple check con la clave net.tcp.service[tcp,,443], y en Triggers una alerta como max(/<host>/net.tcp.service[tcp,,443],#3)=0.

Justo al lado está Data collection → Maintenance. Allí se registran los periodos en que los dispositivos están apagados a propósito – por ejemplo un PC de copias que solo funciona de vez en cuando. Durante esos periodos no se envían correos.

Alerts → Media types y Actions: para que lleguen los correos

Dos sitios deciden si se envía un correo o no:

• Alerts → Media types → Email: servidor SMTP, puerto, cifrado, remitente y credenciales. El enlace Test envía desde aquí un correo de prueba.
• Alerts → Actions → Trigger actions: la acción existente Report problems to Zabbix administrators debe estar en Enabled. Define a quién se avisa de un problema y de su resolución.

Falta el destinatario: registrar la propia dirección en Users → Users → Admin → Media.

El propio HP3: gráficas como en Grafana

Para HP3, Zabbix construyó las gráficas por sí solo a partir de la plantilla Linux: CPU, memoria, carga, red por tarjeta, ocupación de cada dataset ZFS y entrada/salida de disco. Están en Monitoring → Hosts → Graphs o en el panel del host que Zabbix crea automáticamente.

Lo que queda: de todas las entradas del menú, en el día a día se usan cuatro: Problems, Hosts, Latest data y Create host. El resto es configuración que se hace una vez.

🔄 Lo que viene

Algunas comprobaciones existen ahora por duplicado: mi comprobación de disponibilidad de siempre sigue vigilando el blog y Nextcloud, y Zabbix también. Es a propósito. Ambas corren en paralelo unas semanas y luego decidiré si Zabbix sustituye a la antigua. Zabbix tiene a su favor el historial y los tiempos de respuesta; la antigua, que es diminuta y apenas puede fallar.

Igual de importante era para mí poder quitarlo todo de nuevo. Como todo corre rootless con mi usuario, desmontarlo consiste en parar cuatro servicios y borrar cuatro archivos y un directorio. Anoté esos pasos durante el propio montaje.

Hasta ahora, Zabbix solo pregunta a la mayoría de los dispositivos: «¿Sigues ahí?». En el próximo artículo debe mirar dentro de ellos:

• La FRITZ!Box y los repetidores mediante TR-064. No hablan SNMP, pero esta interfaz informa del estado de la línea de internet, la velocidad de sincronización y el número de clientes WLAN. Esa es la verdadera ganancia: un punto de acceso puede responder al ping y aun así haber dejado de emitir WLAN. «Ni un solo cliente desde hace tres horas» es la alerta que de verdad ayuda.
• El switch mediante SNMP. Con la MIB estándar (IF-MIB), Zabbix ve el estado, los errores y el tráfico de cada puerto y avisa cuando un puerto cae.
• El hardware de los servidores mediante iLO. Para ventiladores, temperaturas, fuentes de alimentación y discos, Zabbix trae una plantilla lista que consulta Redfish (HTTP).
• La fotovoltaica. El inversor Fronius tiene su propia interfaz JSON, la Solar API. Zabbix puede consultarla sin software adicional y dibujar gráficos de producción.
• Menos correos durante una caída. Si hoy falla el switch, cada dispositivo detrás de él envía su propio correo. Con dependencias entre las alertas, Zabbix sabe que todo cuelga del switch y solo avisa de él.
• Un segundo canal de aviso, como un mensaje push al móvil (ntfy), por si falla la propia vía del correo. Además, una retención más corta de las mediciones y una copia nocturna de la base de datos.

Y, sinceramente, espero que el primer correo real de Zabbix tarde mucho en llegar.

Lo que queda: hacer correr una herramienta nueva junto a la antigua cuesta poco y muestra si es mejor en el día a día. Anotar desde el principio cómo quitarla elimina el riesgo de probar.

🎯 Las lecciones

1. Una monitorización solo ve aquello para lo que se construyó. Los huecos silenciosos son los dispositivos sin agente.
2. Una alerta solo está demostrada cuando una caída provocada a propósito llega al buzón – resolución incluida.
3. Revisar los valores por defecto: Zabbix no trae de fábrica ninguna acción de correo activa, y la zona horaria es UTC.
4. Con contenedores, los problemas suelen estar en la frontera con el núcleo: capacidades, archivos de dispositivo, montajes.
5. Para pruebas, usar direcciones que seguro no pertenecen a nadie – «no respondió en el escaneo» no significa «libre».

🔧 Anexo: menos escrituras para los SSD

Tras la publicación surgió la pregunta de si las pequeñas escrituras constantes perjudican al RAIDZ de SSD. Así que medí lo que escribe realmente la base de datos: unas 750 transacciones por minuto, de las que algo más de 110 forzaban con fsync una escritura inmediata en disco – casi dos por segundo. Cada fsync impide que ZFS acumule escrituras en la RAM y las escriba en bloque, y en un RAIDZ cada bloque pequeño llega a los discos junto con su paridad.

Medido frente a la vida útil de los SSD, es inofensivo: unos 200 a 300 MB al día son insignificantes para discos diseñados para unos 1.300 TB de escritura cada uno. Como el servidor está conectado a un SAI, aun así configuré PostgreSQL para acumular – cuatro opciones en el archivo Quadlet de la base de datos:

El resultado, por minuto y con una carga comparable:

El precio: si se va la luz pese al SAI, pueden faltar las mediciones de los últimos segundos. La base de datos sigue siendo coherente – con synchronous_commit=off, PostgreSQL solo pierde las transacciones más recientes, nunca daña las anteriores. Para datos de monitorización es un buen intercambio.

Lo que queda: primero medir, luego optimizar. El primer ajuste por sí solo apenas cambió nada; solo la medición mostró que el proceso en segundo plano seguía escribiendo cada pequeño cambio por separado, al ritmo de 200 ms.

Las capturas están anonimizadas: nombres de dispositivos, direcciones IP, dominios y direcciones de correo se sustituyeron por valores neutros antes de tomarlas, y la caída está escenificada.