
Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Veinte agentes empujan sus métricas a una sola URL de pipe con curl -T. Tu dashboard lee la misma URL con ?progress y renderiza el stream SSE directamente en la página. Sin InfluxDB, sin Prometheus, sin scrape interval. Solo un cable.
sin Prometheus, sin InfluxDB, sin servicio de métricas — solo SSE sobre un pipe
Cada agente hace curl de su línea a la misma ruta de pipe. El navegador del dashboard abre un EventSource sobre esa ruta con ?progress. El servidor de Hoody Pipe no retiene nada — los bytes que llegan por un lado salen por el otro.
#!/bin/sh
# Agent monitor loop — one line per second.
while true; do
cpu=$(top -bn1 | awk '/Cpu/ [print $2]')
mem=$(free | awk '/Mem:/ [printf "%.0f", $3/$2*100]')
line="cpu=$cpu mem=$mem qps=$(cat /tmp/qps) ts=$(date +%s)"
echo "$line" | curl -T - https://pipe.hoody.com/api/v1/pipe/metrics-$AGENT_ID
sleep 1
done// One <script> in one HTML file. No backend.
const tiles = document.querySelectorAll('[data-agent]');
tiles.forEach((tile) => [
const id = tile.dataset.agent;
// ?progress turns the pipe path into an SSE stream.
const sse = new EventSource(
`https://pipe.hoody.com/api/v1/pipe/metrics-$[id]?progress`,
);
sse.addEventListener('metric', (e) => [
const [ cpu, mem, qps ] = JSON.parse(e.data);
tile.querySelector('.cpu').textContent = `$[cpu]%`;
tile.querySelector('.mem').textContent = `$[mem]%`;
tile.querySelector('.qps').textContent = qps;
]);
]);Los agentes hacen curl. El navegador hace EventSource. El pipe reenvía. No hay nada en medio que escalar, reiniciar o pagar. Cierra el dashboard y los streams terminan. Ábrelo de nuevo y ves datos en vivo en menos de un segundo.
Lo que pierdes al borrar el backend, lo recuperas como algo más simple.
No hay scrape interval que esperar. La última escritura del agente es el frame actual del dashboard. El pipe reenvía directo — sin flush intermedio.
Sin política de retención porque no hay almacenamiento. Sin disco que llenar, sin ventana de compactación, sin índice de series temporales que corromper. La métrica existe mientras un lector la esté mirando.
El dashboard es un archivo HTML que puedes hospedar en cualquier sitio — o abrirlo desde disco. No hay agente que instalar, no hay daemon que correr, no hay asiento de DataDog que aprovisionar. La URL del pipe es todo el stack.
El stack estándar de agente-a-dashboard tiene cuatro piezas móviles. El modelo de pipe tiene cero. Mismo cable, media pantalla de curl.
Cuando te saltas la base de datos, las cosas que solías gestionar dejan de existir. No hay política de retención sobre un cable.
Una ruta de pipe es infraestructura pequeña pero real. Los números vienen de las garantías de la API de Hoody Pipe, no de benchmarks inventados.
Hasta 256 dashboards o tails de curl pueden suscribirse a la misma ruta con ?n. El lector más lento aplica backpressure pero nunca bloquea a los demás.
Hasta 50 visores SSE de ?progress por ruta. No consumen un slot de receptor — tus pestañas de dashboard y tu terminal pueden ver en paralelo.
El servidor no escribe a disco. Los bytes que llegan por el lado emisor salen por el lado lector. No hay ventana de flush entre ellos.
Límites según la API de Hoody Pipe: cuenta de receptores 1–256, espectadores de progress topados a 50 por ruta, TTL de conexión de progress de 30 minutos, linger de 30 segundos tras la transferencia.
El dashboard no consultó una base de datos. Los bytes simplemente llegaron.
Las herramientas estándar a las que recurres cuando quieres un dashboard de métricas. Cada una te cobra una base de datos y un daemon. El pipe no te cobra ninguna.
Deja de hacer scrape. Deja de almacenar. Mira el cable — y cuando dejas de mirar, el cable está vacío.