Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Vingt agents poussent leurs métriques vers une seule URL pipe avec curl -T. votre dashboard lit la même URL avec ?progress et rend le stream SSE directement dans la page. Pas d'InfluxDB, pas de Prometheus, pas d'intervalle de scrape. Juste un fil.
pas de Prometheus, pas d'InfluxDB, pas de service de métriques — juste du SSE sur un pipe
Chaque agent fait curl de sa ligne dans le même path pipe. Le navigateur du dashboard ouvre un EventSource sur ce path avec ?progress. Le serveur Hoody Pipe ne retient rien — les octets qui arrivent d'un côté ressortent de l'autre.
#!/bin/sh
# Boucle d'agent monitor — une ligne par seconde.
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// Un <script> dans un fichier HTML. Aucun backend.
const tiles = document.querySelectorAll('[data-agent]');
tiles.forEach((tile) => [
const id = tile.dataset.agent;
// ?progress transforme le path pipe en stream SSE.
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;
]);
]);Les agents font curl. Le navigateur ouvre un EventSource. Le pipe transmet. Rien entre les deux à scaler, redémarrer, ou payer. Ferme le dashboard, les streams s'arrêtent. Rouvre-le, et vous voyez les données live à la seconde près.
Ce que vous cèdes en supprimant le backend, vous le récupères en plus simple.
Aucun intervalle de scrape à attendre. La dernière écriture de l'agent est l'image actuelle du dashboard. Le pipe transmet directement — aucun flush intermédiaire.
Aucune politique de rétention puisqu'il n'y a pas de stockage. Aucun disque à remplir, aucune fenêtre de compaction, aucun index time-series à corrompre. La métrique existe pendant qu'un lecteur regarde.
Le dashboard est un fichier HTML que vous héberges où vous voulez — ou que vous ouvrez depuis le disque. Aucun agent à installer, aucun daemon, aucun siège DataDog à provisionner. L'URL pipe est la stack entière.
La stack standard agent-vers-dashboard a quatre pièces mobiles. Le modèle pipe en a zéro. Même fil, un demi-écran de curl.
Quand vous sautez la base de données, les choses que vous gérais cessent d'exister. Pas de politique de rétention sur un fil.
Un path pipe est une infra petite mais réelle. Les chiffres viennent des garanties de l'API Hoody Pipe, pas de benchmarks inventés.
Jusqu'à 256 dashboards ou tails curl peuvent s'abonner au même path avec ?n. Le lecteur le plus lent applique du backpressure mais ne bloque jamais les autres.
Jusqu'à 50 viewers SSE ?progress par path. Ils ne consomment pas de slot receiver — vos onglets dashboard et votre terminal regardent en parallèle.
Le serveur n'écrit pas sur disque. Les octets qui arrivent côté sender ressortent côté reader. Aucune fenêtre de flush entre les deux.
Limites selon l'API Hoody Pipe : 1 à 256 receivers, spectateurs progress plafonnés à 50 par path, TTL connexion progress de 30 minutes, linger post-transfert de 30 secondes.
Le dashboard n'a pas requêté une base de données. Les octets sont juste arrivés.
Les outils par défaut quand vous voulez un dashboard de métriques. Chacun vous facture une base de données et un daemon. Le pipe ne vous facture ni l'un ni l'autre.
Arrêtez de scraper. Arrêtez de stocker. Regardez le fil — et quand vous arrêtez de regarder, le fil est vide.