
Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Zwanzig Agenten schicken ihre Metriken per curl -T an eine Pipe-URL. Dein Dashboard liest dieselbe URL mit ?progress und rendert den SSE-Stream direkt in die Seite. Kein InfluxDB, kein Prometheus, kein Scrape-Intervall. Nur eine Leitung.
kein Prometheus, kein InfluxDB, kein Metrik-Service – einfach SSE auf einer Pipe
Jeder Agent curlt seine Zeile in denselben Pipe-Pfad. Der Browser des Dashboards öffnet eine EventSource auf diesem Pfad mit ?progress. Der Hoody-Pipe-Server hält nichts – Bytes, die auf der einen Seite ankommen, verlassen die andere.
#!/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;
]);
]);Agenten curlen. Der Browser nutzt EventSource. Die Pipe leitet weiter. Dazwischen gibt es nichts, das skaliert, neu gestartet oder bezahlt werden müsste. Schließ das Dashboard und die Streams enden. Öffne es wieder und du siehst innerhalb einer Sekunde Live-Daten.
Was du aufgibst, indem du das Backend löschst, bekommst du als etwas Einfacheres zurück.
Es gibt kein Scrape-Intervall, auf das man warten müsste. Der letzte Write des Agenten ist der aktuelle Frame des Dashboards. Die Pipe leitet direkt weiter – keine Zwischen-Flush.
Keine Aufbewahrungs-Policy, weil es keinen Speicher gibt. Keine Disk, die volllaufen kann, kein Compaction-Fenster, kein Time-Series-Index, der korrumpieren könnte. Die Metrik existiert, solange ein Reader zuschaut.
Das Dashboard ist eine HTML-Datei, die du überall hosten – oder von der Festplatte öffnen kannst. Es gibt keinen Agenten zu installieren, keinen Daemon zu betreiben, keinen DataDog-Sitz zu provisionieren. Die Pipe-URL ist der gesamte Stack.
Der übliche Agent-zu-Dashboard-Stack hat vier bewegliche Teile. Das Pipe-Modell hat null. Gleiche Leitung, ein halber Bildschirm curl.
Wenn du die Datenbank überspringst, hören die Dinge, die du früher verwaltet hast, auf zu existieren. Auf einer Leitung gibt es keine Aufbewahrungs-Policy.
Ein Pipe-Pfad ist kleine, aber echte Infrastruktur. Die Zahlen kommen aus den Garantien der Hoody-Pipe-API, nicht aus erfundenen Benchmarks.
Bis zu 256 Dashboards oder curl-Tails können denselben Pfad mit ?n abonnieren. Der langsamste Reader wendet Backpressure an, blockiert die anderen aber nie.
Bis zu 50 ?progress-SSE-Viewer pro Pfad. Sie verbrauchen keinen Empfänger-Slot – deine Dashboard-Tabs und dein Terminal können parallel zuschauen.
Der Server schreibt nicht auf Disk. Bytes, die auf der Sender-Seite ankommen, verlassen die Reader-Seite. Es gibt kein Flush-Fenster dazwischen.
Limits laut Hoody Pipe API: Empfängeranzahl 1–256, Progress-Zuschauer maximal 50 pro Pfad, 30-Minuten-TTL für Progress-Verbindungen, 30-Sekunden-Linger nach der Übertragung.
Das Dashboard hat keine Datenbank abgefragt. Die Bytes sind einfach angekommen.
Die üblichen Tools, zu denen du greifst, wenn du ein Metriken-Dashboard willst. Jedes berechnet dir eine Datenbank und einen Daemon. Die Pipe berechnet dir keins von beidem.
Hör auf zu scrapen. Hör auf zu speichern. Beobachte die Leitung – und wenn du nicht mehr hinschaust, ist die Leitung leer.