一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / tail-prod-logs-to-a-url / hero
PIPE · 实时日志流
把生产日志 tail 到一个谁都能 curl 的 URL
故障发生。三个工程师都想同时拿到同一份日志。一个发送端把 tail -F 通过管道送进 Hoody Pipe URL,任何拿到链接的人 curl 一下,就能实时看到字节流过去。无堡垒机、无 agent 安装、无仪表盘席位。
prod-app-7 · 发送端
$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
流式中 · 3 个读取者
扇出
READER 1
工程师 A
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
READER 2
工程师 B
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
READER 3
工程师 C
$ curl .../pipe/live
200 GET /v1/orders/8421POST /v1/checkout u_28f500 stripe timeout
use-cases / tail-prod-logs-to-a-url / mechanism
一个发送端。多条 curl。无 agent。
在生产容器里,一行命令把 tail 直接送进 Hoody Pipe URL。接收者 GET 同一路径。管道不存任何东西——字节穿过去。第一个连接的接收者解除发送端的阻塞;最多 256 个读取者可以加入同一路径。
prod-app-7 · /var/log/app
PUT · 发送端# 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)...管道不存任何东西 · 字节穿过去
任意笔记本 · 无需 SSH
GET · 读取者# 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/3Pipe API 的两段:发送端 PUT /api/v1/pipe/[path],每个读取者 GET /api/v1/pipe/[path],通过相同的 n 关联。服务器转发发送端的 Content-Type,在等待读取者时连接最多保持 5 分钟 TTL,如有任何读取者读得慢就反压回去。
use-cases / tail-prod-logs-to-a-url / powers
管道给你的,仪表盘给不了
日志 URL 和 Datadog 席位是不一样的。它按 URL 阅读,不按登录;发送端一停它就消失;它能扩展到一整个事故频道。
MULTIPLAYER BY DEFAULT
一条流,最多 256 个 curl
n=N 在 Pipe API 里有文档:每个用相同 n 加入同一路径的读取者,都会拿到一份等同的扇出副本。SRE、值班、用手机看的创始人——都能同时 tail 这条流。
HTTP 原生
无 agent。无转发器。只要 curl。
读取端什么都不用装。任何说 HTTP 的东西——curl、fetch、浏览器标签、Slack 事故频道里预览的 URL——都是合法的日志 tail。响应体就是字节本身。
短生命周期
ctrl-C,管道就没了
发送端断开,管道消失。无需配置保留期、无日志体积要清理、无暴露在公网的残留端点。URL 是路径,不是地点——故障结束,路径就关闭。
use-cases / tail-prod-logs-to-a-url / capacity
URL 背后的数字
来自 Pipe API 规范。让 URL 像基础设施而不是玩具的限制和行为。
- READERS PER PATH256
n 的文档上限。事故频道不会用完席位。
- BYTES STORED0
管道是端到端直接流式。无中间磁盘、无保留期要管理。
- WAITING TTL5 min
接收者可以先于发送端连接;服务器为该位置保留最多 5 分钟。
来源:Hoody Pipe API——/api/v1/pipe/[path]、n 参数和未建立管道 TTL 的限制均有文档记录。
use-cases / tail-prod-logs-to-a-url / punchline
日志不再是一个地点。它是一条路径。
无堡垒机 · 无席位 · 无转发器一个 URL · 最多 256 条 curl
昨天ssh bastion → tail -f /var/log/app.log
今天https://prod-pipe.../api/v1/pipe/live
use-cases / tail-prod-logs-to-a-url / replaces
它替代了什么
你目前为了让三个工程师盯同一份生产日志要调用的整套工具和仪式。每一项都按席位、按 agent 或按仪表盘收费。管道只是一个 URL。
- Datadog Logs 席位看同一份字节,要按用户买许可
- SSH 堡垒机 + tail -f跳板、SSH、找到日志文件——每个工程师重复一遍
- Loggly / Logtail 转发器agent 安装、配置、保留期账单
- ELK / Splunk 仪表盘为了一个 tail 部署一整套重型栈
- Slack 上分享 tail -f 屏幕一个人 tail,其他人眯着眼看
- 云厂商日志组每个读取者都要控制台席位 + IAM
use-cases / tail-prod-logs-to-a-url / cta
故障结束。你 ctrl-C 发送端,管道消失。没什么要清理的。
use-cases / tail-prod-logs-to-a-url / related
阅读其他内容
