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.
Containers·Snapshots
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeService überwachenFürDevOps & InfraFürDev TeamsServicesPipeWarum HoodyHTTP-nativWarum HoodyMultiplayer von Haus aus
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeService überwachenFürDevOps & InfraFürDev TeamsServicesPipeWarum HoodyHTTP-nativWarum HoodyMultiplayer von Haus aus
use-cases / tail-prod-logs-to-a-url / hero
PIPE · LIVE LOG STREAMING
Produktions-Logs an eine URL streamen, die jeder per curl lesen kann
Ein Feuer bricht aus. Drei Engineers wollen dieselben Logs zur selben Zeit. Ein Sender pipet tail -F in eine Hoody-Pipe-URL. Jeder mit dem Link führt curl aus und sieht die Bytes in Echtzeit vorbeiziehen. Keine Bastion, keine Agent-Installation, kein Dashboard-Sitz.
prod-app-7 · sender
$tail -F /var/log/app/*.log | curl -T - https://prod-pipe.../pipe/live
01200 GET /v1/orders/8421 · 18ms
02POST /v1/checkout user=u_28f payload=ok
03500 POST /v1/checkout · stripe timeout
04retrying charge attempt=2/3
05# auto-rollback armed
06200 POST /v1/checkout · 91ms
Streaming · 3 Leser
fan-out
READER 1
Engineer A
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
READER 2
Engineer B
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
READER 3
Engineer C
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
use-cases / tail-prod-logs-to-a-url / mechanism
Ein Sender. Viele curls. Kein Agent.
Auf dem Prod-Container pipet eine einzige Zeile tail direkt in eine Hoody-Pipe-URL. Empfänger machen GET auf denselben Pfad. Die Pipe hält nichts — Bytes streamen hindurch. Sobald der erste Empfänger verbindet, wird der Sender entblockt; bis zu 256 Leser können denselben Pfad teilen.
prod-app-7 · /var/log/app
PUT · sender# On the production container — one line.
# tail -F follows new lines forever; curl -T - PUTs stdin
# straight into a pipe path. ?n=4 says "wait for 4 readers".
tail -F /var/log/app/*.log \
| curl -T - \
"https://prod-pipe.containers.hoody.com/api/v1/pipe/live?n=4"
# [INFO] Waiting for 4 receiver(s) to connect...
# [INFO] Streaming to 4 receiver(s)...Die Pipe hält nichts · Bytes streamen hindurch
beliebiger Laptop · ssh-frei
GET · readers# Any engineer with the URL — same command, same path.
# The response body IS the live stdout of the sender.
# Up to 256 readers can join. SSE progress is available too.
curl "https://prod-pipe.containers.hoody.com/api/v1/pipe/live?n=4"
# 200 GET /v1/orders/8421 · 18ms
# POST /v1/checkout user=u_28f payload=ok
# 500 POST /v1/checkout · stripe timeout
# retrying charge attempt=2/3Zwei Teile der dokumentierten Pipe-API: PUT /api/v1/pipe/[path] auf dem Sender, GET /api/v1/pipe/[path] auf jedem Leser, beide über dasselbe n verknüpft. Der Server leitet den Content-Type des Senders weiter, hält die Verbindung bis zu 5 Minuten TTL offen, während er auf Leser wartet, und wendet Backpressure an, falls ein einzelner Leser zu langsam ist.
use-cases / tail-prod-logs-to-a-url / powers
Was die Pipe dir gibt, was ein Dashboard nicht kann
Eine Logs-URL verhält sich anders als ein Datadog-Sitz. Sie wird über die URL gelesen, nicht über Login. Sie verschwindet, wenn der Sender stoppt. Und sie skaliert auf einen ganzen Incident-Channel.
MULTIPLAYER BY DEFAULT
Bis zu 256 curls auf einem Stream
n=N ist in der Pipe-API dokumentiert: jeder Leser, der demselben Pfad mit demselben n beitritt, bekommt eine identische Fan-out-Kopie. SREs, On-Call, der Founder, der vom Handy zuschaut — alle verfolgen denselben Stream gleichzeitig.
HTTP-NATIV
Kein Agent. Kein Forwarder. Nur curl.
Auf der Empfängerseite gibt es nichts zu installieren. Alles, was HTTP spricht — curl, fetch, ein Browser-Tab, ein Slack-Incident-Channel mit URL-Vorschau — ist ein gültiger Log-Tail. Die Bytes sind der Response-Body.
EPHEMER
ctrl-C, und die Pipe ist weg
Wenn der Sender die Verbindung trennt, verschwindet die Pipe. Keine Retention zu konfigurieren, kein Log-Volumen aufzuräumen, kein verwaister Endpoint, der ans Internet hängt. Die URL war ein Pfad, kein Ort — und der Pfad schließt, wenn das Feuer endet.
use-cases / tail-prod-logs-to-a-url / capacity
Die Zahlen hinter der URL
Aus der Pipe-API-Spec. Limits und Verhalten, die eine URL wie Infrastruktur wirken lassen statt wie Spielzeug.
- LESER PRO PFAD256
Das dokumentierte Limit für n. Deinem Incident-Channel gehen die Plätze nicht aus.
- GESPEICHERTE BYTES0
Die Pipe wird Ende-zu-Ende direkt gestreamt. Keine Zwischen-Disk, keine Retention zu verwalten.
- WARTE-TTL5 min
Empfänger können sich vor dem Sender verbinden; der Server hält den Slot bis zu 5 Minuten.
Quelle: Hoody Pipe API — Limits dokumentiert für /api/v1/pipe/[path], n-Parameter und unestablished Pipe-TTL.
use-cases / tail-prod-logs-to-a-url / punchline
Logs sind kein Ort mehr. Sie sind ein Pfad.
keine Bastion · kein Sitz · kein Forwardereine URL · bis zu 256 curls
gesternssh bastion → tail -f /var/log/app.log
heutehttps://prod-pipe.../api/v1/pipe/live
use-cases / tail-prod-logs-to-a-url / replaces
Was das ersetzt
Die Tools und Rituale, die du heute aufrufst, um drei Engineers auf dieselben Prod-Logs starren zu lassen. Jedes davon kostet pro Sitz, pro Agent oder pro Dashboard. Die Pipe ist eine URL.
- Datadog Logs SitzeLizenz pro Nutzer, um dieselben Bytes zu sehen
- SSH-Bastion + tail -fHop, ssh, Logfile finden, pro Engineer wiederholen
- Loggly / Logtail ForwarderAgent-Installation, Konfig, Retention-Rechnung
- ELK / Splunk DashboardsSchwerer Stack, um einen einzigen Tail zu hosten
- Slack Screenshare von tail -fEiner tailt, der Rest schielt
- Cloud-Provider Log-GruppenKonsolen-Sitz plus IAM pro Leser
use-cases / tail-prod-logs-to-a-url / cta
Das Feuer endet. Du drückst ctrl-C beim Sender. Die Pipe verschwindet. Es gibt nichts aufzuräumen.
use-cases / tail-prod-logs-to-a-url / related
Lies die anderen
