コンテンツにスキップ
use-cases / tail-prod-logs-to-a-url / hero
PIPE · ライブログストリーミング

誰でも curl できる URL に本番ログを tail

障害が発生。3 人のエンジニアが同時に同じログを見たい。1 つの送信側が tail -F を Hoody Pipe URL に流し込む。リンクを持つ人は誰でも curl を実行し、バイトがリアルタイムで流れるのを見られる。踏み台なし、エージェントのインストールなし、ダッシュボードのシートなし。

パイプのドキュメントを読む
use-cases / tail-prod-logs-to-a-url / mechanism

1 つの送信側、複数の curl、エージェントなし。

本番コンテナで、1 行が 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/3

ドキュメント化された Pipe API の 2 つの部分: 送信側の 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 で読まれる。送信側が止まると消える。そしてインシデントチャンネル全体にスケールする。

デフォルトでマルチプレイヤー

1 つのストリームに最大 256 個の curl

n=N は Pipe API でドキュメント化されている: 同じ n で同じパスに参加するすべてのリーダーは、同一のファンアウトコピーを受け取る。SRE、オンコール、スマートフォンから見守る創業者 — すべてが同じストリームを同時に tail する。

HTTP ネイティブ

エージェントなし。フォワーダーなし。ただの curl。

リーダー側にインストールするものは何もない。HTTP を話すもの — curl、fetch、ブラウザタブ、URL をプレビューする Slack インシデントチャンネル — はすべて有効なログ tail。バイトはレスポンスボディそのもの。

エフェメラル

ctrl-C でパイプは消える

送信側が切断すると、パイプは消える。設定する保持期間なし、クリーンアップするログ容量なし、インターネットに残るエンドポイントなし。URL は場所ではなくパスだった — そしてそのパスは火事が終わると閉じる。

use-cases / tail-prod-logs-to-a-url / capacity

URL の背後にある数値

Pipe API 仕様より。URL を玩具ではなくインフラのように感じさせる制限と動作。

  1. パスあたりのリーダー256

    n のドキュメント化された上限。あなたのインシデントチャンネルがシート切れになることはない。

  2. 保存バイト数0

    パイプはエンドツーエンドで直接ストリーミング。中間ディスクなし、管理する保持期間なし。

  3. 待機 TTL5 分

    受信側は送信側より先に接続できる; サーバーは最大 5 分間スロットを保持する。

出典: Hoody Pipe API — /api/v1/pipe/[path]、n パラメータ、未確立パイプの TTL についてドキュメント化された制限。

use-cases / tail-prod-logs-to-a-url / punchline

ログはもう場所ではない。パスだ。

踏み台なし · シートなし · フォワーダーなし1 つの URL · 最大 256 個の curl
昨日ssh 踏み台 → tail -f /var/log/app.log
今日https://prod-pipe.../api/v1/pipe/live
パイプ API を読む
use-cases / tail-prod-logs-to-a-url / replaces

これが置き換えるもの

現在、3 人のエンジニアが同じ本番ログを見つめるために起動している一連のツールと儀式。それぞれがシート、エージェント、ダッシュボードごとに課金する。パイプは 1 つの URL。

  • Datadog Logs シート同じバイトを見るためのユーザーごとのライセンス
  • SSH 踏み台 + tail -fホップ、ssh、ログファイル探索、エンジニアごとに繰り返し
  • Loggly / Logtail フォワーダーエージェントのインストール、設定、保存料金
  • ELK / Splunk ダッシュボード1 つの tail をホストするための重いスタック
  • Slack で tail -f を画面共有1 人が tail し、残りは目を凝らす
  • クラウドプロバイダーのロググループコンソールのシート + リーダーごとの IAM
use-cases / tail-prod-logs-to-a-url / cta

障害が終わる。送信側を ctrl-C する。パイプは消える。クリーンアップするものは何もない。

パイプ API を読む
use-cases / tail-prod-logs-to-a-url / related

他のユースケースを読む