El problema no era la métrica, era la pantalla
Netdata hace un trabajo notable recolectando métricas: CPU, memoria, red, disco, contenedores, todo con una resolución que a veces raya en excesiva. El problema apareció cuando quise revisar el servidor desde el celular, parado en la cocina, sin ganas de abrir el notebook. La interfaz web oficial de Netdata está pensada para un monitor grande, con decenas de gráficos simultáneos, paneles densos y una navegación que en una pantalla de 6 pulgadas se vuelve casi inutilizable. Podía ver los datos, pero no podía leerlos rápido, que es justo lo que uno necesita cuando solo quiere confirmar que todo sigue arriba.
La opción fácil era resignarme. La otra era preguntarme qué tan difícil era construir exactamente lo que necesitaba, ni más ni menos.
Consumir la misma API, sin la misma interfaz
Netdata expone su propia API REST con toda la información que muestra en pantalla, así que la solución no requería tocar nada del stack existente: bastaba con un servicio liviano en Node.js que golpeara esa API cada cierto tiempo, filtrara lo que realmente me importa a diario (CPU, memoria, estado de los contenedores) y lo sirviera en una página pensada desde cero para celular. Para el estado de los contenedores usé directamente el socket de Docker, que da información más precisa sobre qué está corriendo, reiniciado o caído que cualquier métrica derivada.
El resultado es un contenedor más, corriendo detrás del mismo Cloudflare Tunnel que expone Home Assistant y el resto de los servicios, con su propio subdominio de ulloa.cc. Nada de puertos nuevos abiertos, nada de infraestructura adicional: solo otro servicio Docker consumiendo dos fuentes de datos que ya existían.
Nada de framework, a propósito
No usé ningún framework de frontend ni backend pesado. Para un servicio que hace fetch a dos APIs y renderiza un puñado de tarjetas, un framework completo es puro overhead: más superficie para mantener, más dependencias que actualizar, más cosas que pueden romperse sin que yo las esté tocando. Es la misma lógica que apliqué antes con un llamador de números de Bingo para un evento presencial: Node.js y Socket.IO puro, sin nada de por medio entre la idea y el código. Cuando el problema es acotado, escribir la solución mínima suele tomar menos tiempo que evaluar, instalar y configurar una herramienta genérica que resuelve un problema diez veces más grande que el tuyo.
Monitorear también es parte de la seguridad
Este dashboard terminó siendo útil más allá de las métricas de hardware. Cuando armé fail2ban para SSH, con su ban progresivo, aprendí algo que no es obvio hasta que te topas con eso: un ban a nivel de firewall no sirve de nada contra tráfico que entra por el túnel de Cloudflare, porque ese tráfico nunca toca directamente el firewall del servidor. La protección real para los servicios expuestos por el túnel tiene que vivir a nivel de aplicación, no de red. Eso cambió qué es lo que me interesa vigilar día a día: no solo si el servidor está vivo, sino si algún servicio está recibiendo tráfico raro o si un contenedor se reinició solo sin que yo lo haya pedido. Detalles que en un dashboard genérico se pierden entre veinte gráficos, y que en uno hecho a medida puedo poner arriba de todo.
La lección que se repite
Esta no es la primera vez que la solución termina siendo "escribir cuarenta líneas propias" en lugar de "aprender a usar una herramienta ajena para un caso de uso que no es el mío". Netdata sigue siendo la fuente de verdad, sigue corriendo, sigue recolectando todo con el mismo detalle. Lo único que cambió es la capa que decide qué de todo eso vale la pena mostrar y cómo. Esa separación —motor de datos por un lado, interfaz por otro— es la misma que uno diseña en cualquier sistema de producción, solo que acá el "cliente" soy yo mismo revisando el celular antes de acostarme.