Durante una temporada tuve la tentación de monitorizarlo todo. CPU, RAM, discos, contenedores, logs, latencias, certificados, temperatura, consumo, backups, colas, procesos y cualquier cosa que pudiera acabar en una gráfica bonita. Es una fase normal del homelab. Instalas Grafana, empiezas a añadir paneles y de repente parece que tienes un NOC en miniatura en casa.
El problema es que la monitorización también se convierte en un servicio más. Hay que mantenerla, actualizarla, entender por qué un exporter se ha caído, pelearse con etiquetas, revisar dashboards que nadie mira y gestionar alertas que empiezan avisando de cosas útiles y acaban siendo ruido de fondo.
Con el tiempo he ido cambiando el enfoque. Ahora prefiero una monitorización por capas: primero saber si algo está vivo, después entender si una máquina se está quedando sin recursos y solo al final meter sistemas más pesados para servicios que de verdad lo justifican.
En un homelab doméstico, muchas veces Uptime Kuma y Beszel cubren casi todo lo importante. Grafana sigue teniendo sitio, pero no lo pondría por defecto en cada instalación pequeña. Es brillante cuando necesitas correlacionar métricas, histórico largo y paneles a medida. Para saber si el NAS respira y si el mini PC lleva tres días al 95 por ciento de RAM, puede ser demasiado aparato.
Qué quiero saber de verdad#
Antes de instalar nada, conviene separar curiosidad de necesidad. A mí me gusta ver gráficas, no voy a fingir lo contrario. Pero una gráfica bonita no siempre ayuda a tomar decisiones.
En casa, las preguntas importantes suelen ser estas:
- ¿El servicio responde?
- ¿El certificado va a caducar?
- ¿La máquina tiene CPU, RAM y disco suficientes?
- ¿Hay algún contenedor reiniciándose en bucle?
- ¿Los backups se han ejecutado?
- ¿Hay un disco dando señales raras?
- ¿Me está llegando una alerta útil o solo ruido?
Esa lista es bastante terrenal. No necesito empezar con un stack completo de observabilidad para responderla. Necesito señales claras y pocas alertas.
Mi error al principio fue montar la herramienta antes de definir las preguntas. Eso lleva a dashboards enormes que impresionan cinco minutos y luego no abres nunca. La monitorización útil tiene que empujar decisiones: apagar algo, ampliar disco, restaurar un backup, revisar un cable, cambiar una política de actualizaciones.
Si no cambia ninguna acción, probablemente sobra.
Capa 1: Uptime Kuma para lo que tiene que contestar#
Uptime Kuma me parece una de las mejores piezas de software para homelab porque hace una cosa muy concreta y la hace bien: comprobar si algo responde.
Lo uso para servicios web, endpoints internos, certificados, puertos TCP y algunas comprobaciones básicas. No intenta ser Prometheus. No intenta explicarme cada métrica del sistema. Solo responde a una pregunta simple: esto que uso, ¿está arriba o no?
Ahí encaja muy bien.
Servicios típicos que pondría en Uptime Kuma:
- Home Assistant.
- El panel de Proxmox o del virtualizador principal.
- NAS o interfaz de almacenamiento.
- Gestor de contraseñas si lo tienes self-hosted.
- DNS interno.
- Reverse proxy.
- Servicios publicados hacia fuera.
- Página estática o blog si lo sirves tú.
También sirve para comprobar certificados. Esto parece menor hasta que un certificado caduca en el peor momento y un servicio que estaba vivo empieza a parecer roto. Una alerta unos días antes ahorra bastante teatro.
La clave está en no meter absolutamente todo. Si añades veinte servicios experimentales que rompes cada semana, Uptime Kuma deja de ser un panel de salud y se convierte en una lista de tus juguetes a medio montar. Yo separaría lo estable de lo experimental. Lo que usa la casa va al panel serio. Lo que estoy probando puede vivir en otro dashboard, o directamente fuera.
Capa 2: Beszel para saber cómo están las máquinas#
Beszel me gusta porque ocupa el espacio entre “solo uptime” y “observabilidad completa”. Instalas agentes ligeros, conectas máquinas y tienes CPU, RAM, disco, red, contenedores y estado general en un panel limpio. No hace falta montar medio ecosistema para empezar a ver cosas útiles.
En un homelab con varios mini PCs, un NAS y alguna VM de servicios, esa visión rápida vale oro. No necesito recordar en qué nodo está cada cosa para ver cuál está cargado. Abro el panel y veo si hay una máquina tragando RAM, si un disco se está llenando o si un contenedor lleva reinicios sospechosos.
La ventaja frente a un Grafana casero montado rápido es la fricción. Beszel se despliega en poco tiempo y no te obliga a diseñar el sistema de métricas desde cero. Eso tiene límites, claro. Si quieres consultas complejas, retención larga, correlación entre servicios o dashboards muy específicos, se queda corto. Pero para el 80 por ciento de un homelab pequeño, esa limitación es parte de la gracia.
Menos piezas. Menos mantenimiento. Menos posibilidades de que el sistema que vigila todo sea lo que más trabajo da.
Lo que miro en Beszel:
- RAM sostenida por encima de lo normal.
- CPU alta sin motivo claro.
- Discos que pasan del 80 por ciento.
- Tráfico raro en una máquina que debería estar tranquila.
- Contenedores reiniciándose.
- Temperaturas si el hardware lo expone bien.
No necesito mirar eso cada día. De hecho, si tengo que mirarlo cada día, algo está mal diseñado. Lo uso como panel de inspección rápida antes de tocar cosas o cuando noto que un servicio va raro.
Cuándo Grafana sí merece la pena#
Grafana no es el villano. Al contrario, es una herramienta fantástica. El problema es usarla como respuesta automática para cualquier homelab.
Yo la usaría cuando aparece una de estas necesidades:
- Quieres histórico serio de métricas durante meses.
- Necesitas cruzar datos de varias fuentes.
- Tienes servicios con carga real y quieres entender patrones.
- Quieres medir consumo, temperatura y rendimiento de forma consistente.
- Necesitas dashboards compartidos o muy personalizados.
- Ya tienes Prometheus, InfluxDB, Loki u otra fuente de datos bien planteada.
Grafana brilla cuando hay preguntas concretas. Por ejemplo: ¿la carga del servidor sube cuando se ejecutan backups? ¿El consumo de RAM crece con cada actualización de un servicio? ¿La latencia interna cambia cuando hay sincronización de fotos? ¿Un nodo concreto se calienta más que el resto?
Ahí sí. Ahí merece la pena.
Lo que no haría es montar Grafana solo porque queda profesional. Un dashboard de veinte paneles que no miras nunca es decoración técnica. Muy vistosa, pero decoración.
También hay que contar el coste mental. Prometheus necesita exporters. Los exporters cambian. Algunas métricas desaparecen. Otras cambian de nombre. Loki necesita entender ingesta de logs y retención. InfluxDB tiene sus propias decisiones. Nada de esto es imposible, pero todo suma.
En casa, cada pieza que añades tiene que justificar su mantenimiento.
Logs: el agujero donde se puede perder una tarde#
Los logs son otro tema delicado. Centralizarlos suena obvio. Luego descubres que los logs crecen, que muchos servicios escupen basura, que retener demasiado consume disco y que buscar bien requiere disciplina.
Para un homelab pequeño, yo no empezaría centralizando todos los logs. Empezaría por los servicios críticos y por los errores que de verdad quiero poder investigar.
Ejemplos razonables:
- Reverse proxy.
- DNS interno.
- Home Assistant si mueve cosas importantes.
- Servicios expuestos hacia fuera.
- Backups.
- Automatizaciones que pueden fallar en silencio.
No necesito mandar cada log de cada contenedor de pruebas a Loki. Eso es fabricar trabajo. Prefiero tener logs locales accesibles y centralizar solo lo que me ayuda a reconstruir incidentes.
Una regla simple: si no sabes qué harías con ese log, no lo ingieras todavía.
Alertas: pocas y con intención#
Las alertas son donde más se estropean los homelabs. Al principio quieres que todo avise. Luego tienes Telegram, ntfy, email o Discord pitando por tonterías. Al tercer falso positivo dejas de leerlas. Y una alerta que no lees es peor que no tener alerta, porque te da una falsa sensación de control.
Mis alertas mínimas serían:
- Servicio crítico caído durante más de unos minutos.
- Certificado próximo a caducar.
- Disco por encima de un umbral peligroso.
- Backup fallido.
- Máquina sin responder.
- Temperatura muy alta.
- Reinicios repetidos de un contenedor importante.
No alertaría por CPU alta de forma instantánea. La CPU sube. Es normal. Alertaría si se mantiene alta durante bastante tiempo y coincide con degradación real. Tampoco alertaría por cada servicio de laboratorio que apago a propósito.
La alerta buena tiene tres cualidades: llega a tiempo, se entiende rápido y pide una acción concreta. Si solo dice “algo está raro” y me obliga a investigar media hora cada vez, acabará ignorada.
Mi arquitectura ligera#
Si tuviera que montar hoy una monitorización sensata para un homelab doméstico, empezaría así:
- Uptime Kuma para disponibilidad y certificados.
- Beszel para métricas de máquinas y contenedores.
- Scrutiny o la herramienta del NAS para salud de discos.
- Comprobaciones específicas de backup con salida clara.
- Logs locales bien conservados para servicios no críticos.
- Grafana solo si hay una necesidad concreta de análisis.
Esto no es lo más sofisticado. Es precisamente la idea.
La arquitectura ligera tiene una ventaja brutal: se entiende. Si algo falla, sé dónde mirar. Si una alerta llega, sé qué sistema la generó. Si quiero añadir una máquina nueva, no tengo que tocar cinco piezas distintas.
En un entorno empresarial grande, esto se quedaría corto. En una casa, suele ser bastante. Y si no lo es, crecer desde una base simple es mejor que empezar sobredimensionado.
Retención: cuánto histórico guardar#
Otro punto que se suele ignorar: no todo histórico merece vivir para siempre.
Para uptime y certificados, me basta con semanas o pocos meses. Para métricas de máquinas, guardar varios meses puede ayudar a detectar tendencias de disco, RAM o temperatura. Para logs, prefiero retención corta salvo en servicios concretos.
Guardar datos tiene coste. Disco, backups, mantenimiento y privacidad. No necesito conservar durante años cada petición HTTP interna de mi casa. Necesito saber qué pasó cuando algo se rompió y tener suficiente contexto para arreglarlo.
Una política razonable:
- Uptime: 90 días.
- Métricas básicas: 90 a 180 días.
- Logs normales: 7 a 30 días.
- Logs críticos: algo más si hay motivo.
- Backups de configuración de las herramientas: sí, siempre.
Esto último importa. Si Uptime Kuma o Beszel se rompen, quiero poder levantarlos de nuevo con sus monitores, agentes y configuración. La monitorización también necesita backup. Es irónico, pero pasa.
Qué no monitorizaría al principio#
Hay cosas que dejaría fuera hasta tener una razón clara:
- Métricas de cada contenedor experimental.
- Logs completos de servicios de prueba.
- Alertas por pequeñas variaciones de CPU.
- Dashboards de negocio si el servicio no tiene usuarios reales.
- Exporters raros solo porque existen.
- Temperatura de cada sensor si luego no puedes actuar.
La pregunta práctica es: si esto cambia, ¿haré algo?
Si la respuesta es no, no merece alerta. Quizá merece una gráfica por curiosidad, pero no una notificación. Y quizá ni eso.
El homelab tiene una trampa muy elegante: convertir el mantenimiento del laboratorio en el hobby principal. No siempre es malo. A veces justo queremos trastear. Pero si hay servicios que usa la familia, conviene separar el juguete del sistema estable.
Señales de que te has pasado#
Para mí hay varios síntomas claros de exceso:
- Recibes alertas que no lees.
- Tienes dashboards que no abres desde hace meses.
- Actualizar la monitorización da más miedo que actualizar los servicios monitorizados.
- No sabes qué componente genera una alerta.
- El sistema de métricas consume recursos notables en máquinas pequeñas.
- Has añadido más exporters que servicios importantes.
- Nadie en casa nota la diferencia, salvo cuando algo pita de madrugada.
Ese último punto es cruel, pero bastante real. Si la monitorización no mejora la estabilidad de lo que la casa usa, quizá solo mejora nuestra sensación de control.
Mi recomendación final#
Para un homelab pequeño o mediano, empezaría simple: Uptime Kuma para disponibilidad, Beszel para recursos y una comprobación seria de backups. Después añadiría piezas según dolor real.
Grafana lo reservaría para cuando tenga preguntas que las herramientas ligeras no contestan. No lo descartaría. Simplemente no lo pondría en el centro desde el primer día.
La mejor monitorización no es la que más métricas recoge. Es la que te avisa de pocas cosas, pero importantes, y te permite entender rápido qué se rompió. Todo lo demás puede esperar.
Y si un dashboard no cambia ninguna decisión, bórralo sin pena. El homelab ya genera bastante polvo digital él solo.