Monitorización sin estrés: qué métricas realmente importan en tu homelab

Instalar Prometheus, Grafana y veinte exporters es el rito de iniciación de todo homelab. Durante los primeros meses, pasas horas configurando dashboards que muestran temperaturas de CPU, latencia de DNS, uso de inodos y tráfico de red por interfaz. Es satisfactorio ver tantos números cambiar en tiempo real. El problema viene después: nadie mira esos dashboards, las alertas se acumulan, y terminas con ciento cincuenta métricas que no te dicen nada útil. He pasado por eso. He tenido veinte gráficos abiertos y no me he enterado de que el servidor de backups llevaba tres días caído.

El error de monitorizar todo

La cultura de la observabilidad empuja a recolectar datos masivos. Más métricas, más logs, más trazas. En un entorno empresarial con equipos dedicados, eso tiene sentido. En un homelab gestionado por una persona en su tiempo libre, es una trampa. Cada métrica que recopilas consume tres recursos: disco para almacenarla, CPU para procesarla, y atención tuya para interpretarla. Cuando tienes quinientas métricas, ninguna es importante. Cuando tienes cinco, sí lo son.

Mi punto de inflexión llegó cuando mi stack de monitorización (Prometheus, Grafana, Loki, Tempo, Alertmanager) consumía más recursos que los servicios que supuestamente supervisaba. El contenedor de Prometheus solito tomaba 4GB de RAM. Me di cuenta de que estaba ejecutando una plataforma de observabilidad empresarial para vigilar tres servidores y una instancia de Jellyfin. Era como usar un avión de carga para llevar una carta.

Las únicas cinco métricas que necesitas

Tras reducir drásticamente, me quedé con cinco indicadores que realmente previenen problemas. Primera: disponibilidad del servicio. No latencia ni throughput: simplemente, ¿responde o no? Un health check básico cada cinco minutos contra los endpoints críticos. Segunda: uso de disco. No porcentaje de CPU ni carga de sistema: el disco se llena, y cuando se llena, todo se detiene. Es la causa número uno de caídas en infraestructura pequeña. Tercera: estado de los backups. No cuándo se ejecutaron: si se restauran correctamente. Un backup que no restaura es datos perdidos con extra steps.

Cuarta: certificados SSL próximos a expirar. En un homelab con Lets Encrypt y dominios propios, los certificados caducan. Es aburrido hasta que deja de serlo. Quinta: presencia de actualizaciones de seguridad. No versión del kernel ni parches menores: solo si hay actualizaciones críticas pendientes. Estas cinco métricas, monitoreadas con un script simple y notificaciones por Telegram o Matrix, han detectado el cien por cien de los problemas reales que he tenido en los últimos doce meses.

El caso contra los dashboards

Los dashboards son una ilusión de control. Parecen útiles porque muestran mucha información, pero la información no es acción. Un gráfico de uso de CPU durante las últimas veinticuatro horas no te dice qué hacer ahora. Una alerta que dice "el disco está al noventa por ciento" sí. En mi experiencia, los dashboards solo sirven para dos cosas: justificar decisiones ya tomadas, o fingir que entiendes qué pasa.

He sustituido Grafana por notificaciones push directas. Un script en Python que corre cada diez minutos, comprueba las cinco métricas, y envía un mensaje solo cuando algo cruza un umbral. No hay interfaz web, no hay gráficos, no hay base de datos de series temporales. Solo texto plano cuando importa. El código cabe en cien líneas, consume menos de cincuenta megabytes de RAM, y nunca se ha caido.

Alertas que no alertan

El segundo error grave es alertar demasiado. Cuando recibes veinte notificaciones al día, aprendes a ignorarlas todas. Es el efecto del vecino que grita ladrón cada noche: cuando realmente hay un ladrón, nadie responde. Mis reglas ahora son estrictas. Una alerta debe cumplir tres condiciones: indica un problema que requiere acción inmediata, no se resolverá solo, y la acción está claramente definida. Si falta alguna de las tres, no es una alerta: es ruido.

Por ejemplo, "uso de CPU alto" no cumple ninguna de las tres. No requiere acción inmediata, a menudo se resuelve solo, y la acción no está definida (¿escalar? ¿matar procesos? ¿ignorar?). En cambio, "disco raíz al noventa y cinco por ciento, servicios críticos en riesgo" cumple las tres: requiere actuar ya, no se arregla solo, y la acción es liberar espacio o expandir volumen.

Logs: menos es más

Loki era mi sistema de logs centralizado. Ahora uso journalctl del host y logs locales de Docker. No porque Loki no funcione: funciona demasiado bien, y eso es el problema. Recopila todo, y "todo" incluye millones de líneas de health checks de traefik, mensajes de debug de aplicaciones, y advertencias de bibliotecas que no controlas. Buscar algo útil en ese océano es imposible sin aprender un lenguaje de consulta que olvidas entre uso y uso.

Mi aproximación actual es simple. Cada servicio loguea a stdout. Los contenedores de Docker los capturan automáticamente. Si un servicio falla, ejecuto docker logs y veo las últimas cincuenta líneas. Eso resuelve el noventa por ciento de los problemas. Para el diez por ciento restante, hay técnicas de rotación y retención de logs que evitan llenar el disco. No necesito buscar logs de hace tres meses porque si no resolví el problema en tres días, ya no es relevante.

La arquitectura de monitorización minimalista

Mi stack actual es deliberadamente simple. Un script Python que corre como cron job cada diez minutos. Comprueba health checks HTTP de servicios críticos, espacio en disco de volúmenes montados, fecha de expiración de certificados SSL, y estado de restauración del último backup. Los resultados se envían a un canal de Matrix. Si todo está bien, no dice nada. Si algo falla, manda un mensaje conciso. No hay base de datos, no hay interfaz web, no hay dependencias externas salvo la librería requests.

Para métricas históricas ocasionales, uso las herramientas del sistema: htop para procesos, iostat para disco, ss para red. No necesito gráficos bonitos para saber que un proceso consume demasiada CPU. Necesito saber qué proceso es y por qué. Las herramientas interactivas del sistema operativo responden eso más rápido que cualquier dashboard.

Conclusión

La observabilidad empresarial no escala hacia abajo. No necesitas las mismas herramientas que una startup con cincuenta microservicios para vigilar tres contenedores en un NAS. La monitorización efectiva en un homelab no es la que más datos recopila: es la que más rápido te dice qué está roto y cómo arreglarlo. Reduce tu stack, elimina los dashboards que no miras, configura alertas solo para lo que realmente importa, y acepta que a veces la mejor herramienta de monitorización es ssh y tu sentido común.

El tiempo que ahorras sin mantener Prometheus, Grafana y sus dependencias lo puedes invertir en cosas que sí importan: actualizar servicios, mejorar backups, o simplemente disfrutar de que tu infraestructura funciona sin que tengas que vigilarla cada hora. La mejor infraestructura es la que no necesita ser vigilada constantemente. Si tu homelab te exige más atención que un gato, algo has diseñado mal.