メトリクスとアナリティクス

ある時点の Workers トラフィックについて、グラフで見られる情報源は 2 つあります。Workers メトリクスと、ゾーン単位の Workers アナリティクスです。

Workers メトリクスは、Worker のパフォーマンスと使用量を示し、問題の切り分けやワークロードの把握に役立ちます。Worker がゾーン上のルート、または複数ゾーンで動いている場合、ゾーンごとの処理量と、サイトが受けているリクエスト数を確認できます。

ゾーンアナリティクスは、そのゾーンに割り当てたすべての Workers が処理しているトラフィック量を示します。

Workers メトリクスは、個別の Worker のリクエストデータを集計します（Worker が複数ドメインと *.workers.dev で動いている場合は、それらをまとめて集計します）。Worker のメトリクスを表示するには、次の手順を実行します。

ある時点の Worker の健全性を把握するのに役立つメトリクスは 2 つあります。リクエストの成功 / エラーと、呼び出しステータスです。

最初のグラフは、Workers ランタイムからの過去のリクエスト数を、成功、エラー、サブリクエストに分けて示します。

• 合計: Worker が登録したすべての受信リクエストです。WAF ↗ やその他のセキュリティ機能でブロックされたリクエストは数えません。
• 成功: 呼び出しステータスが Success または Client Disconnected だったリクエストです。
• エラー: 呼び出しステータスが Script Threw Exception、Exceeded Resources、または Internal Error だったリクエストです。エラーの内訳は 呼び出しステータス を参照してください。

時間範囲が 6 時間未満のとき、グラフ末尾の数分でトラフィックが落ちて見えることがあります。実際のトラフィック低下ではなく、集計とメトリクス配信のわずかな遅延です。

サブリクエストは、Worker 内から fetch を呼んで発生するリクエストです。未捕捉エラーをスローしたサブリクエストは数えません。

• 合計: Worker 内から fetch を呼んで発生したすべてのサブリクエストです。
• キャッシュ済み: キャッシュされたレスポンスが返された件数です。
• 未キャッシュ: キャッシュされていないレスポンスが返された件数です。

ウォールタイム は、 Worker の呼び出し開始から、これ以上 JavaScript を実行する必要がないと Workers ランタイムが判断するまでの経過時間（ミリ秒）です。 具体的には、実行あたりのウォールタイムのグラフは、JavaScript コンテキストが 開いていたウォールタイムを測ります。I/O 待ち時間と、Worker の waitUntil() ハンドラー内の実行時間も含みます。 ウォールタイムは、Worker がレスポンスの最終バイトをクライアントへ送り終わるまでの時間とは異なります。 レスポンス送信後も waitUntil() 内のタスクが動いていれば、ウォールタイムの方が長くなります。 逆に短くなることもあります。たとえば大きな本文のレスポンスを返すとき、Workers ランタイムは これ以上 JavaScript を実行する必要がないと判断し、すべてのバイトが通過・送信される前に JavaScript コンテキストを閉じることがあります。

実行あたりのウォールタイムのグラフは、過去のウォールタイムを リザーバーサンプリング ↗ で関連する分位点に分けて示します。分位点の読み方 ↗ も参照してください。

実行あたりの CPU 時間のグラフは、過去の CPU 時間を リザーバーサンプリング ↗ で関連する分位点に分けて示します。分位点の読み方 ↗ も参照してください。高い分位点が CPU 時間の上限 を超えて見えても、呼び出しエラーが出ないことがあります。CPU 上限未満のリクエスト分の CPU 時間を繰り越せる、Workers ランタイムの仕組みのためです。

リクエストあたりの Duration グラフは、Worker 呼び出しあたりの過去の 実行時間 を示します。データは CPU 時間のグラフと同様、関連する分位点に分かれます。分位点の読み方 ↗ も参照してください。Worker 自体でまとまった計算をする予定があるときは、実行時間の把握が特に役立ちます。

メモリ使用量のグラフは、各呼び出し時点で Worker が使う V8 アイソレートのメモリ量を、リザーバーサンプリング ↗ で P50、P90、P99、P999 のパーセンタイルに分けて示します。詳細は 分位点の読み方 ↗ を参照してください。

Workers は V8 アイソレート 上で動き、それぞれに 128 MB のメモリ上限 があります。1 つのアイソレートは多数の同時リクエストを処理し、メモリを共有します。メモリ使用量メトリクスは、各呼び出し時点でこの共有メモリのうちどれだけ使われているかを表します。

グラフ上のデプロイマーカーで、メモリの変化と特定のコードデプロイを突き合わせられます。新しいバージョンがメモリ回帰を起こしたかどうかの切り分けに使えます。

メモリ使用量が時間とともに右肩上がりなら、メモリリークの可能性があります。ローカルで DevTools のメモリプロファイリング を使い、ヒープスナップショットを取って、消費が大きいオブジェクトを特定してください。

呼び出しステータスを確認するには、次の手順を実行します。

Worker の呼び出しステータスは、Workers ランタイム内で Worker が正常に実行されたか、レスポンスを生成できなかったかを示します。呼び出しステータスは HTTP ステータスコード とは異なります。Worker の呼び出しは成功しても、Workers ランタイム外の別エラーにより、成功の HTTP ステータスにならないことがあります。一部の呼び出しステータスでは、クライアントに Workers エラーコード が返されます。

¹ Exceeded Resources ステータスは、Worker が ランタイム上限 を超えたときに出ることがあります。最も多い原因は CPU 時間の使いすぎですが、起動時間や Free プランの上限超過でも発生します。

² Internal Error ステータスは、システム内部の障害で Workers ランタイムがリクエストを処理できなかったときに出ることがあります。Worker のコードやリソース上限が原因ではありません。Internal Error のリクエストはまれですが、通常運用でも出ることがあります。これらのリクエストは請求の使用量には数えません。Internal Error の割合が高い場合は www.cloudflarestatus.com ↗ を確認してください。

例外をさらに調べるには wrangler tail を使います。

リクエスト所要時間のグラフは、コード実行と I/O 待ちを含め、Worker がリクエストに応答するまでの時間を示します。このグラフは、Worker で Smart Placement が有効な場合にのみ利用できます。

実行時間 が Worker の稼働時間だけを測るのに対し、リクエスト所要時間は、リクエストがデータセンターに入ってからレスポンスが届くまでの時間を測ります。

データは、Smart Placement が有効なリクエストと、無効なリクエスト（デフォルトではリクエストの 1% が Smart Placement 無効でルーティングされます）を比較します。グラフはヒストグラムで、横軸が所要時間、縦軸がその所要時間に収まるリクエストの割合です。

Worker メトリクスは、最大 3 か月前まで、1 週間単位で確認できます。

ゾーンアナリティクスは、ゾーンに定義した任意の ルート に割り当てた、すべての Workers のリクエストデータを集計します。

ゾーンメトリクスを確認するには、次の手順を実行します。

Cloudflare ダッシュボードで、対象ゾーンの Workers Analytics ページを開きます。

ゾーンデータは、直近 30 日以内の時間範囲で絞り込めます。ダッシュボードには、次のグラフと情報が含まれます。

このグラフは、Worker 内から fetch を呼んで発生するサブリクエストを、キャッシュ状態別に示します。

• 未キャッシュ: オリジンサーバー、またはサブリクエストに応答する他のサーバーが直接返したリクエストです。
• キャッシュ済み: Cloudflare の キャッシュ ↗ が返したリクエストです。Cloudflare がコンテンツをより多くキャッシュするほど、配信が速くなり、オリジンの負荷が下がります。

このグラフは、ゾーン上のすべての Workers の過去の帯域幅使用量を、キャッシュ状態別に示します。

このグラフは、ゾーン上のすべての Workers の過去のリクエストを、HTTP ステータスコード別に示します。

このグラフは、ゾーン上のすべての Workers の過去のデータを、成功リクエスト、失敗リクエスト、サブリクエストに分けて示します。これらのリクエスト種別は HTTP ステータスコードで分類し、200 番台は成功、400 から 500 番台は失敗です。

Worker メトリクスは GraphQL で動いています。データセットの照会方法は GraphQL で Workers メトリクスを照会するチュートリアル を参照してください。

上記のメトリクスは、Worker のパフォーマンスとランタイム挙動を把握するためのものです。アプリ固有のカスタムアナリティクスには Workers Analytics Engine を使います。

Analytics Engine は次の用途に向いています。

• カスタムのビジネスメトリクス — サインアップ、購入、機能利用など、アプリ固有のイベントを追跡します。
• 顧客単位のアナリティクス — 顧客 ID や API キーなど、カーディナリティの高い次元でデータを記録します。
• 使用量ベースの請求 — API 呼び出し、コンピュート単位、その他の課金イベントを顧客ごとに数えます。
• パフォーマンス追跡 — 応答時間、キャッシュヒット率、エラー率を、カスタム次元付きで測ります。

Analytics Engine への書き込みはノンブロッキングで、Worker にレイテンシを足しません。データは Analytics Engine SQL API で SQL 照会するか、Grafana で可視化できます。

始め方は Analytics Engine の例 を参照してください。