Cloudflare Worker telemetry でイベントを送信して確認する
制御されたアプリケーション境界で Cloudflare Worker telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
エッジ API 監視
- 2
契約を定義する
worker_name、route_template、メソッド、status_code、コロ、および trigger_type
- 3
結果で発行する
ctx.waitUntil は、失敗が観察された配信約束に対してのみ使用してください。それ以外の場合、ワーカーはテレメトリがフラッシュされる前に戻ることができます。
- 4
証拠を検証する
Exercise a known fixture, then inspect edge_request_completed for one correctly typed terminal row.
始める前に
始める前に
- Telemetry API キーのワーカー シークレット バインディング
- 明示的に管理されたバックグラウンド配信に ExecutionContext が利用可能
- 正規化されたルート名と Cloudflare リクエスト メタデータのホワイトリスト
配信設定
サーバー側のインストールと初期化
サーバー専用コードで telemetry-sh をインポートし、process.env.TELEMETRY_API_KEY で一度初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install telemetry-sh- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Cloudflare Worker telemetryイベント
await telemetry.log("edge_request_completed", {
worker_name: "events-api",
route_template: "/api/events",
method: "POST",
status_code: 202,
colo: request.cf?.colo,
latency_ms: 42,
status: "success",
release: env.APP_RELEASE,
});イベントスキーマ
worker_name、route_template、メソッド、status_code、コロ、および trigger_type
ステータス、latency_ms、利用可能な場合は cpu_time_ms、および error_type
request_id、queue_name、試行、リリース、および環境
設定を確認する
チェックポイント 1
ctx.waitUntil は、失敗が観察された配信約束に対してのみ使用してください。それ以外の場合、ワーカーはテレメトリがフラッシュされる前に戻ることができます。
チェックポイント 2
生の URL ではなくルート テンプレートを記録し、Cookie、認証ヘッダー、リクエスト本文、クライアント IP アドレス、または無制限の cf プロパティをログに記録しません。
チェックポイント 3
ランタイム診断用にワーカー ログを保存し、すべてのコンソール レコードを複製するのではなく、レビューされたアプリケーションの結果についてコンパクトな Telemetry イベントを発行します。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Cloudflare Worker telemetry 検証クエリ
SELECT *
FROM edge_request_completed
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
イベントを記録する場所
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの例
このワークフローのイベントスキーマ
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
その他のSQL例
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
ルートごとの API リクエスト スループットの計算
1 分あたり最も多くのリクエストを処理している API ルートはどれですか?
レシピを開くAPI 429 レート制限回復の測定
HTTP 429 を受信したリクエストは、再試行後に正常に回復しますか?
レシピを開くルート別のAPIエラー率の計算
リクエストが 20 件以上ある API ルートのうち、5xx エラー率が最も高いのはどれですか？
レシピを開くp50、p95、p99 API レイテンシの計算
テール レイテンシが最も悪いエンドポイントはどれですか?
レシピを開くAPI エラーバジェット燃焼率の計算
API は 99.9% の可用性予算をどれくらいの速さで消費していますか?
レシピを開く欠落しているサービスのハートビートを検出する
ハートビートの送信を停止したと予想されるテレメトリ ソースはどれですか?
レシピを開くルートとリリースごとにコア Web バイタルを比較
フロントエンドのパフォーマンスが最も弱いルートとリリースはどれですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
Pino 構造化イベント分析
Pino 診断ログを、Node.js リクエスト、ジョブ、および製品の信頼性分析のために、制限された Telemetry 結果イベントと組み合わせます。
オープンガイドNestJS リクエストとワークフロー Telemetry
正規化されたルート結果、レイテンシー、エラー、リリース、承認されたアカウント コンテキストを使用して NestJS コントローラーとプロバイダーを計測します。
オープンガイドGoogle Cloud Run テレメトリ
Cloud Run のリクエストとジョブの結果、コールドスタート コンテキスト、インスタンスの同時実行性、再試行、レイテンシ、リリースをアプリケーション所有の構造化イベントで追跡します。
オープンガイド