Cloudflare Traces の紹介：プラットフォーム全体でリクエストを追跡
エッジにリクエストが入ると、インターセプトされ、書き換えられ、Worker に引き継がれ、キャッシュにヒットする。これらの判断はこれまでそれぞれのログに散在していた。Traces はその経路全体をエクスポート可能な OpenTelemetry トレースとしてつなぎ、agent に調査させることもできる。
日本語
コピー
Cloudflare Traces の発表：プラットフォーム全体でリクエストを追跡
本日、Cloudflare Traces のベータ版を公開します。Workers の自動トレースをリクエスト経路の残りの部分へと拡張するものです。1 本の trace の中で、対応するセキュリティルール、変換、キャッシュの判断、ルーティング、Worker の実行、オリジンでの処理までを確認でき、その trace は Cloudflare 上やオリジン、あるいはスタックの他の場所で動くサービスへとそのまま続いていきます。これは OpenTelemetry への長期的な取り組みであり、Cloudflare をスタックの中で最も可観測性の高い部分にするための取り組みでもあります。現在、次のことができます。
- Cloudflare をまたいでリクエストを自動トレース：対応するプラットフォームの処理を、追加設定なしでリクエスト単位のタイムラインに記録します。
- どのリクエストをトレースするかを制御：ベースラインのサンプリングレートを設定し、Trace Rules で一致するトラフィックに対してそのレートを上書きできます。
- エンドツーエンドの trace コンテキスト伝播：W3C traceparent ヘッダーを受け取り、転送します。
- Cloudflare 内で trace を調査：Cloudflare ダッシュボードで直接、リクエストのタイムラインと span の詳細を確認できます。
- OpenTelemetry で trace をエクスポート：OpenTelemetry Protocol (OTLP) 互換のエンドポイントを通じて、span を任意の宛先へ送信できます。
任意のドメインでCloudflare ダッシュボードからトレースを有効化できます。エージェントに設定させることも可能です。
私たちが Cloudflare をデバッグするときに使っている可視性を、あなたの手に
私たち自身のチームが調査に使う内部 trace は、1 本に数千の span が含まれることも珍しくなく、それらは数十のサービスと機能によって生成されます。おかげでリクエストのあらゆる細部まで掘り下げられます。この可視性は私たちの内部システムだけにとどめておくべきではないと考えました。
Workers Tracing は、プラットフォーム内部を公開する第一歩でした。昨年、Worker の呼び出しに対する自動計装を公開し、アウトバウンド fetch と、KV、R2、D1、Durable Objects、その他の Workers への呼び出しを対象にしました。これにより、操作ごとにトレース用のコードを書かなくても、Workers ランタイム内部で行われている処理が見えるようになりました。
Cloudflare Traces が目指すのは、Cloudflare を使うすべてのユーザーが同じレベルの可視性を得られるようにすることです。Cloudflare 上でアプリを構築している場合でも、オリジンの前に Cloudflare を置いているだけの場合でも変わりません。トラフィックが私たちのプラットフォームをどう流れていくのかが見え、Cloudflare の設定をリクエスト処理の時間やルーティングの判断といった結果と突き合わせられます。
リクエストをエンドツーエンドで追跡する
Cloudflare 内部でのリクエストの経路はかなり複雑になり得ます。セキュリティルール、変換、ルーティング、キャッシュを通ったり、別のサービスへプロキシされたりします。Cloudflare Traces は対応する各ステップを span として記録し、所要時間、結果、関連する属性を含めます。散在するログと設定からリクエストを組み立て直す必要はなく、システム全体をどう流れたかを 1 か所で確認できます。
次のような問いに答えられます。
リクエストがブロックまたはチャレンジされたのはなぜで、どのセキュリティルールが発火したのか？
カスタムルールまたはマネージドルールがそのリクエストをいつ評価したか、評価にどれだけかかったか、最終的にどのアクションが実行されたかを確認できます。span のイベントから、ブロックやチャレンジの原因となったルールを特定できます。
URL はアプリに届く前に Transform Rule で書き換えられたか？
http_request_transform span を展開すると、変更箇所ごとに、影響を受けたリクエストの構成要素と対応するルールがわかります。この変換が、ルーティングやオリジンでの処理に対してどの段階で起きたかも見えます。
どの Page Rules、Snippets、Workers がこのリクエストを処理または変更したか？
workers_routing span は、ルートが一致したかどうか、どのルートタイプが使われたか、一致したルートパターンを示します。
レスポンスはキャッシュから返されたのか？ 時間は Cloudflare、オリジン接続、アプリのどこで費やされたのか？
ネストされた cache、upstream、origin の span を展開すると、リクエストの時間がどこで費やされたかがわかります。次の例ではキャッシュミスでオリジンへ戻り、539ms のうち 527ms をレスポンスの待機に費やしています。
トレースを設定する
特別な計装も設定もプラグインも要りません。あるドメインでトレースを有効にすれば、Cloudflare がこれらの span を自動的に生成します。オープン標準に従っていれば、サードパーティのサービスへトレースを広げ、再び Cloudflare に戻すこともできます。そのうえで、ベースラインのサンプリングレートと Trace Rules を使って、どのリクエストをトレースするかを制御できます。
ベースラインサンプリングレートを設定する
どのドメインでもトレースを有効化し、ベースラインサンプリングレートを設定することで、可視性・データ量・コストのバランスを取れる。通常運用ではリクエストの1%だけをトレースすれば、すべてのリクエストでtraceを収集しなくても、リクエストの挙動を継続的に観察できる。
Trace Rules を設定する
Trace Rulesを使えば、ベースラインサンプリングレートを低く保ったまま、特定の調査のために完全なtraceを収集できる。ある顧客から問題の報告が来たら、その顧客のホスト名・送信元IP・識別用のリクエストヘッダーに対して100%のトラフィックをトレースし、残りは1%のままにしておける。調査中に一時的なデバッグヘッダー付きのリクエストだけを100%トレースし、それ以外はベースラインに流すこともできる。ドメイン全体のトレース率を上げずに問題を再現できる。
Trace Rules は同じ Cloudflare Rules language を使うので、パス・メソッド・ヘッダー・IPアドレス・地理位置情報、あるいはこれらの組み合わせでマッチできる。
trace context を受け取り、伝播させる
最も多く寄せられる要望のひとつが、真の分散トレーシングだ。1本のtraceがリクエストに沿ってCloudflareに入り、私たちのプラットフォームを通り、あなたのスタックの残りの部分へと続いていく。
Cloudflare Traces は受信リクエストの W3C traceparent header を受け取り、リクエストが私たちのプラットフォームに到達する前から始まっていたtraceにCloudflareのspanを参加させられる。受信伝播ポリシーが、Cloudflareがそのcontextを受け入れるかどうかを決める。
Cloudflare は新しい traceparent リクエストヘッダーをあなたのオリジンへ転送することもできる。インストルメンテーションを組み込んだ他のサービスならどれでもこのcontextを抽出でき、API・データベース・Cloudflare上や他のプラットフォームで動くサービスをまたいでトレーシングが続く。すべてを1本のつながったtraceとして見たいなら、Cloudflareのspanとアプリ自身のspanを同じOpenTelemetry互換バックエンドに送ればよい。
トレースを可観測性プラットフォームへエクスポートする
OTLPを通じてCloudflareのspanを互換性のある可観測性プラットフォームへエクスポートでき、スタックの他の部分から届くテレメトリデータと並んで表示される。アカウントレベルの送信先を設定し、どのドメインがそこへトレースを送るかを選ぶ。OpenTelemetryへの取り組みの一環であり、Cloudflareはリクエストの活動をOpenTelemetry spanとして表現し、OTLPで送信することで、データが可観測性ツール間でポータブルであり続ける。
あなたの agent に Cloudflare Traces を調査させる
コーディングagentに本番環境の問題を調査させるとき、agentはコードを読み、テストを走らせられても、本番環境でリクエストが何を経験したかまでは見えないことがある。Cloudflare Observability MCP serverがあれば、agentは私たちのSQL APIを使ってトレースデータ（そしてあなたの可観測性データすべて！）をクエリでき、本番のテレメトリデータを調査する能力を得る。
agentに関連するリクエストを見つけさせ、失敗したtraceと成功したtraceを比較し、spanがどこで分岐し始めるかを特定させる。agentはあなたのコードリポジトリも見られるので、これらの発見を該当するコードに対応づけ、変更が必要な範囲を絞り込み、レビュー用の修正を提出するのを手伝える。
料金
Cloudflare Traces は統一された Cloudflare 可観測性の料金モデルに組み込まれる。料金はspanやイベントの数ではなく、書き込む可観測性データの量と保持期間で決まる。新しい料金は2026年12月1日からCloudflare Tracing（そしてWorkers Tracing！）で全面的に適用される。
| プラン | 含まれる使用量 | 保持期間 | 追加使用量 |
|---|---|---|---|
| Free | 1日あたり0.5 GBの取り込み量 | 7日間 | 利用不可 |
| Paid および Enterprise | 請求サイクルごとに50 GBの取り込み量 | ||
| 10 GB-月のストレージ量 | 最長1年 | ||
| （近日提供予定） | 取り込み量 1 GBあたり$0.25 | ||
| ストレージ量 1 GB-月あたり$0.10 |
次のステップ
オープンベータの後、私たちは以下を計画している：
- より広い自動インストルメンテーション：HTTPリクエスト経路（例：DDoS ルール、Access）とWorkersの実行経路（例：Workflows、Queues、Pipelines）にspanを追加する。
- 認証されたcontext伝播：信頼できる呼び出し元が既存のtraceを継続できるようにし、受信リクエストごとにcontextを受け入れる必要をなくす。
- アドホックトレーシング：ベースラインサンプリングレートを変えずに、特定のリクエストをオンデマンドでキャプチャする。
- Workers での OpenTelemetry API サポート：OpenTelemetry API の整備を続け、既存のspanに属性を追加したりtrace contextを取得したりできるようにする。
- より長い保持期間：より長い調査を支えるため、traceデータを最長365日保持する。
はじめに
Cloudflare Traces のドキュメントに沿って最初のリクエストをトレースし、Trace Rules でサンプリングを調整できます。Cloudflare Traces はオープンベータ版で、dashboard、API、Terraform から利用できるほか、OTLP エンドポイントへのエクスポートにも対応しています。