Durante bastante tiempo miré la monitorización del homelab como la mira casi todo el mundo al principio: CPU, RAM, temperatura, disco y un dashboard que quedara bien. No lo digo con desprecio. Una gráfica limpia tiene algo hipnótico, sobre todo cuando acabas de montar Prometheus, Grafana, Beszel o cualquier panel que convierte tus servidores en una especie de sala de control doméstica.
El problema es que una casa no se rompe normalmente porque un mini PC esté al 63 por ciento de CPU.
Se rompe porque el DNS deja de responder y nadie puede navegar. Porque el certificado de un servicio caduca y parece que la aplicación ha muerto. Porque los backups llevan dos semanas fallando en silencio. Porque un disco empieza a dar avisos raros y no los has visto. Porque una actualización reinicia el contenedor equivocado. Porque Home Assistant cae justo cuando alguien intenta apagar una luz desde el móvil. Cosas muy poco vistosas, pero mucho más cercanas a la vida real.
Si tuviera que montar hoy la monitorización de un homelab familiar desde cero, no empezaría por un panel enorme de métricas. Empezaría por una lista corta de preguntas incómodas.
¿Qué servicio tiene que funcionar para que la casa no se enfade? ¿Qué dato me dolería perder? ¿Qué alerta merece interrumpirme? ¿Qué puede esperar al resumen diario? ¿Qué necesito saber si estoy cansado y algo falla a las once de la noche?
La monitorización útil no es la que más mide. Es la que te evita descubrir los problemas cuando ya han tocado la puerta.
CPU y RAM importan menos de lo que parece#
No estoy diciendo que CPU y RAM no importen. Importan, claro. Si una máquina se queda sin memoria, si un contenedor se come todos los recursos o si una VM está saturada cada noche, conviene verlo. Pero en un homelab familiar suelen ser indicadores de segunda capa.
Primero necesito saber si los servicios que sostienen la casa están vivos. Después, si los datos están protegidos. Luego, si la infraestructura se está degradando. Al final miro recursos.
El orden cambia mucho la forma de monitorizar.
Una máquina puede ir perfecta de CPU y tener backups rotos. Puede estar fresquita y perder resolución DNS. Puede tener RAM de sobra y un certificado caducado. Puede mostrar un uptime precioso y estar guardando fotos familiares en un volumen sin copia buena.
Ese es el tipo de falsa tranquilidad que me preocupa.
En casa, una gráfica de CPU alta no siempre exige acción. A veces es una transcodificación, una indexación de fotos o una tarea nocturna. En cambio, un backup fallido tres días seguidos sí merece atención. Un disco con sectores reasignados también. Un DNS sin plan B, más todavía.
Por eso pondría CPU y RAM en el panel, pero no en el centro del sistema. Son contexto, no el diagnóstico completo.
Lo primero: servicios que hacen que internet parezca roto#
Hay servicios que, cuando fallan, no se perciben como “se ha caído mi homelab”. Se perciben como “internet no funciona”. Esa diferencia importa porque cambia la presión doméstica.
El DNS es el caso más obvio. Si usas Pi-hole, AdGuard Home, Unbound o un DNS interno para nombres de casa, ese servicio pasa a ser infraestructura base. Cuando cae, la tele no carga, el móvil se queda pensando y todo el mundo culpa al WiFi. Da igual que la fibra esté perfecta.
Yo monitorizaría el DNS de tres maneras:
- respuesta local a una consulta normal
- respuesta a un dominio externo conocido
- resolución de un nombre interno importante
No hace falta hacerlo complejo. Uptime Kuma puede comprobar DNS. Un script simple también. Lo importante es no limitarse a ver si el contenedor está “up”. Un contenedor puede estar levantado y no resolver bien.
También miraría el router, el punto de acceso principal y el acceso a internet desde dentro de la red. Si tienes un firewall propio con OPNsense, pfSense o similar, ese panel debería estar entre los primeros. Si dependes del router del operador, al menos conviene tener una prueba desde algún host interno hacia fuera.
La pregunta no es “¿mi router responde?”. La pregunta buena es “¿un móvil de casa puede resolver y salir a internet aunque el homelab esté tocado?”.
Si la respuesta depende de demasiadas piezas, hay que revisar arquitectura, no añadir otra alerta.
Backups: la alerta que no puedes dejar para cuando apetezca#
Los backups son el sitio donde más fácil es mentirse. Ves que hay una tarea programada, sabes que existe una carpeta de destino y el cerebro rellena el resto con optimismo barato. Hasta que necesitas restaurar.
En un homelab familiar, monitorizar backups no debería significar solo comprobar que el job terminó. Yo miraría cuatro cosas:
- última ejecución correcta
- tamaño razonable de la copia
- antigüedad del último backup válido
- prueba periódica de restauración de una muestra
La última es la que más pereza da y la que separa una copia de seguridad de una decoración cara.
No hace falta restaurar todo cada semana. Pero sí puedes restaurar un archivo, una foto, una base de datos pequeña o una configuración importante en una ubicación temporal. Si eso falla, prefiero enterarme un martes cualquiera que el día que alguien pregunte por fotos de hace dos años.
Para servicios con datos familiares, marcaría objetivos distintos. No todas las copias merecen la misma urgencia.
Fotos, documentos y gestor de contraseñas tienen prioridad alta. Configuración de Home Assistant también, si controla cosas de casa y no solo sensores curiosos. Multimedia descargable, dashboards y servicios de laboratorio pueden tener una política más relajada. Tratar todo igual suele acabar en dos extremos: o no proteges bien lo importante o te ahogas intentando proteger tonterías.
Una alerta útil sería: “no hay backup correcto de fotos desde hace 48 horas”. Una alerta mala sería: “job backup-photos terminó con código no cero” sin más contexto. La primera me dice impacto. La segunda me manda a leer logs cuando igual estoy con la cena.
Discos y almacenamiento antes que contenedores bonitos#
El almacenamiento avisa antes de morir muchas veces. No siempre, por desgracia, pero bastantes. Si usas NAS, ZFS, Unraid, discos USB o cualquier mezcla doméstica, deberías mirar salud de discos antes que una colección enorme de métricas de contenedores.
Monitorizaría:
- estado SMART
- errores de lectura o escritura
- capacidad usada por pool o volumen
- snapshots que crecen sin control
- scrub o comprobaciones periódicas
- espacio libre real en el destino de backup
El espacio libre merece más respeto del que recibe. Un volumen lleno rompe servicios de formas bastante creativas. Bases de datos que no escriben, backups incompletos, contenedores que arrancan mal, logs que se comen lo que queda. Todo muy divertido si te gusta perder una tarde.
El umbral del 80 por ciento suele ser buena primera alarma, pero no lo usaría a ciegas. En un disco pequeño, pasar del 80 al 100 puede ocurrir rápido. En un pool grande, quizá tienes margen. Lo sensato es mezclar porcentaje con gigas libres y ritmo de crecimiento.
También miraría la edad de los snapshots. Los snapshots son maravillosos hasta que se convierten en una papelera infinita. Si un dataset tiene snapshots antiguos que ya no cumplen ninguna función, quiero verlo. No como emergencia, pero sí como tarea de mantenimiento.
Y si uso ZFS o Unraid, quiero saber si hubo errores después de un scrub o parity check. No necesito una tesis, solo una señal clara: sano, revisar, urgente.
Certificados, dominios y cosas pequeñas que rompen servicios grandes#
Los certificados son una avería tonta con consecuencias enormes. Un servicio puede estar funcionando perfectamente y aun así parecer caído porque HTTPS empieza a quejarse. Si además lo usa alguien que no sabe ni quiere saber qué es un certificado, el fallo se transforma en “esto no va”.
Monitorizaría caducidad de certificados internos y externos con margen suficiente. Treinta días está bien como aviso suave. Siete días ya debería molestar. Menos de eso es una colleja operativa.
También revisaría dominios si hay servicios publicados. No hace falta montar un sistema empresarial. Basta con tener controladas las piezas que convierten una aplicación en algo accesible:
- certificado válido
- DNS público correcto
- reverse proxy respondiendo
- servicio final sano
- renovación automática funcionando
La parte importante es comprobar la cadena completa. Si solo miro que el contenedor esté vivo, puedo perder el fallo real. Si solo miro el dominio desde fuera, no sé dónde se rompió. Necesito ambas vistas.
Para servicios internos haría algo parecido. Si uso nombres tipo home.mi-casa.local o un dominio propio para la LAN, quiero comprobar que resuelven desde dentro y que el reverse proxy devuelve una respuesta esperada. No por perfeccionismo. Porque cuando eso falla, afecta a varias aplicaciones de golpe.
Servicios familiares: medir impacto, no orgullo técnico#
Aquí hay que ser un poco cruel con el propio ego. No todos los servicios del homelab importan lo mismo.
Para mí, los candidatos a monitorización seria serían:
- DNS y red base
- Home Assistant si controla rutinas reales
- fotos familiares
- documentos
- gestor de contraseñas
- copias de seguridad
- acceso remoto de emergencia
- NAS o almacenamiento principal
Después vendrían servicios cómodos: multimedia, recetas, RSS, bookmarks, dashboards, automatizaciones no críticas. Los vigilaría, pero con menos urgencia.
Y por último laboratorio: Kubernetes de pruebas, modelos locales, apps nuevas, bases de datos temporales, paneles que estoy evaluando. Si eso cae, no quiero una alerta con sonido de emergencia. Quiero, como mucho, una marca en un dashboard separado.
Este punto parece organizativo, pero es técnico. Si mezclas servicios críticos y juguetes en el mismo panel con la misma severidad, acabas ignorando todo. La fatiga de alertas no es una teoría de empresa grande. En casa también pasa. Empiezas atendiendo cada aviso y acabas silenciando el chat porque un contenedor experimental lleva tres días reiniciándose.
La clasificación por impacto evita eso.
Una alerta de fotos familiares sin backup reciente debe pesar más que un monitor de Jellyfin caído. Un DNS que no resuelve pesa más que una VM de pruebas apagada. Home Assistant caído puede ser importante o no según la casa. Si solo lo usas para mirar sensores, quizá no pasa nada. Si controla calefacción, luces o rutinas que otros usan a diario, sube de categoría.
La monitorización buena conoce esa diferencia.
Dependencias: qué se cae si apago esta máquina#
Uno de los ejercicios más útiles que he hecho en homelab es dibujar dependencias. Sin florituras. Máquina, servicios, datos, backups y quién depende de quién.
La pregunta que uso es simple: si apago este servidor, ¿qué deja de funcionar?
Al principio suele salir una lista más incómoda de lo esperado. El DNS estaba en la misma máquina que el reverse proxy. El gestor de contraseñas dependía de una base de datos que vive en otro nodo sin backup claro. Las fotos familiares dependen del NAS, pero también de una VM que monta el volumen por red. Home Assistant guarda backups en el mismo sitio que intentaría restaurar si todo arde.
No hace falta resolverlo todo en una noche. Pero sí conviene saberlo.
Monitorizar dependencias no significa comprar una herramienta rara. Puede ser una página en el wiki, un diagrama simple o una tabla mantenida a mano. Lo importante es que, cuando cae algo, no tengas que reconstruir el mapa desde memoria.
En alertas, esto se traduce en una idea práctica: agrupar fallos relacionados. Si cae el host que contiene DNS, reverse proxy y Uptime Kuma, no necesito veinte alertas diciendo que cada servicio está muerto. Necesito saber que el host base está caído y qué impacto tiene.
Menos ruido. Más contexto.
Alertas: pocas, claras y con dueño#
Una alerta que no cambia ninguna acción sobra. Esta regla me ahorra mucha tontería.
Para un homelab familiar, dividiría alertas en tres niveles.
Nivel urgente: internet de casa afectado, DNS caído sin respaldo, almacenamiento con error serio, backup crítico demasiado antiguo, servicio familiar importante caído, acceso remoto de emergencia roto.
Nivel revisar hoy: disco por encima de umbral, certificado cerca de caducar, contenedor crítico reiniciado varias veces, backup no crítico fallido, actualización pendiente con impacto de seguridad.
Nivel resumen: laboratorio caído, servicios cómodos apagados, uso de CPU alto puntual, cambios de estado que no afectan a nadie.
No todo tiene que llegar por Telegram, móvil o push. De hecho, no debería. El canal urgente tiene que mantenerse limpio. Si lo llenas de ruido, el día que avise de algo serio lo vas a ignorar.
También me gusta que la alerta diga qué mirar después. No un manual entero, pero sí una pista: servicio afectado, host, última copia correcta, impacto estimado y enlace al panel o runbook si existe.
“DNS principal caído, respaldo activo, impacto bajo” es una buena alerta.
“Monitor down” es una manera elegante de repartir frustración.
Mi stack mínimo para vigilarlo sin montar una central nuclear#
No empezaría con un stack enorme. Para una casa normal, pondría algo así:
- Uptime Kuma para servicios, certificados y checks simples
- Beszel para máquinas, contenedores y recursos generales
- monitorización SMART o herramienta del NAS para discos
- alerta específica de backups desde el propio sistema de copia
- una página de inventario con dependencias y prioridades
Grafana, Prometheus y Loki los reservaría para cuando haya una necesidad clara: histórico serio, varias máquinas, logs centralizados, métricas personalizadas o ganas reales de mantenerlo. Son herramientas muy buenas. También son más piezas que pueden romperse.
Si el homelab es pequeño, prefiero algo que mire todas las semanas a un dashboard espectacular que solo abro cuando estoy enseñando el montaje.
La mejor monitorización doméstica tiene que sobrevivir a la pereza, al cansancio y al paso de los meses. Si requiere demasiado cariño, se convierte en otro servicio crítico. Y ya tenemos suficientes.
Lo que revisaría cada mes#
Además de alertas automáticas, haría una revisión mensual corta. Nada ceremonial. Quince o veinte minutos con una lista fija:
- backups críticos con última fecha correcta
- restauración de una muestra pequeña
- estado de discos y scrub o comprobación equivalente
- certificados con menos de treinta días
- servicios familiares caídos o inestables
- almacenamiento por encima del umbral
- dispositivos que llevan demasiado tiempo sin actualizar
- alertas repetidas que ya nadie atiende
La última línea es importante. Una alerta repetida que nadie atiende no es una alerta. Es ruido con pretensiones.
También miraría si algún servicio ha cambiado de categoría. A veces instalas algo como prueba y seis meses después lo usa toda la casa. Eso tiene que reflejarse en backups, alertas y mantenimiento. El homelab no falla solo por tecnología. Falla porque las decisiones antiguas se quedan congeladas mientras el uso real cambia.
Mi criterio final#
Si tuviera que resumirlo en una decisión práctica, sería esta: monitoriza primero lo que rompe la vida diaria, luego lo que protege datos, después lo que avisa de degradación y al final los recursos.
CPU, RAM y temperatura están bien. Me gusta verlas. Pero no deberían distraer de lo que importa en una casa: internet, DNS, backups, discos, certificados, servicios familiares y dependencias entendibles.
Un homelab familiar no necesita parecer un centro de operaciones. Necesita avisar antes de que un fallo técnico se convierta en una discusión doméstica o en una pérdida de datos. Menos panel bonito y más señales que te hagan actuar.
Ese cambio de enfoque parece menos espectacular, pero es el que separa un laboratorio entretenido de una infraestructura casera que puedes mantener sin acabar odiándola.