Next.js Server Event Analytics: 境界から検証された行まで
制御されたアプリケーション境界で Next.js Server Event Analytics を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
サーバーアクションの結果
- 2
契約を定義する
route_template または action_name
- 3
境界を計測する
Telemetry 呼び出しをルート ハンドラー、サーバー アクション、またはその他のサーバー専用モジュールに保持します。
- 4
証拠を検証する
Exercise a known fixture, then inspect project_created for one correctly typed terminal row.
始める前に
前提条件と境界
- サーバー専用の TELEMETRY_API_KEY 環境変数
- サーバー コードで初期化された telemetry-sh パッケージ
- 成功と失敗の定義が文書化された名前付きワークフロー
配信設定
サーバー側のインストールと初期化
サーバー専用コードで telemetry-sh をインポートし、process.env.TELEMETRY_API_KEY で一度初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install telemetry-sh- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Next.js Server Event Analyticsイベント
export async function POST(request) {
const startedAt = performance.now();
const result = await createProject(request);
await telemetry.log("project_created", {
route_template: "/api/projects",
status: "success",
status_code: 201,
latency_ms: Math.round(performance.now() - startedAt),
account_id: result.accountId,
source: "onboarding",
});
return Response.json({ id: result.id }, { status: 201 });
}イベント契約
route_template または action_name
ステータス、status_code、および error_type
latency_ms とセーフ アカウントまたはリクエスト ID
実装のチェックポイント
チェックポイント 1
Telemetry 呼び出しをルート ハンドラー、サーバー アクション、またはその他のサーバー専用モジュールに保持します。
チェックポイント 2
ワークフローで処理された失敗などの既知の結果が得られた後、イベントを記録します。
チェックポイント 3
API キーを NEXT_PUBLIC 変数に入れたり、生のフォーム データを送信したりしないでください。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Next.js Server Event Analytics 検証クエリ
SELECT *
FROM project_created
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
生産境界
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの開始点
このワークフローのイベント コントラクト
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します ダッシュボード
検証された製品または収益のクエリを、焦点を絞った意思決定の表面に変えます。
関連する SQL レシピ
SQL で次の質問に答えてください
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
リリースごとの API 信頼性の比較
どのリリースで、より悪い API エラーまたはテール レイテンシーが発生しますか?
レシピを開くSQL でサインアップからアクティベーションまでのファネルを構築する
新しいユーザーは最初の値に到達する前にどこから離れてしまうのでしょうか?
レシピを開く取得元ごとのファネル コンバージョンの比較
どの獲得ソースがアクティブ化するユーザーを生み出しますか?
レシピを開くルートとリリースごとにコア Web バイタルを比較
フロントエンドのパフォーマンスが最も弱いルートとリリースはどれですか?
レシピを開く機能ロールアウトエラー率の比較
機能フラグのロールアウトは、コントロール コホートよりも信頼性が低いですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合
Supabase および Postgres アプリ Telemetry
製品ワークフロー、データベース隣接ジョブ、API ルート、および顧客対応の障害をサーバー コードから追跡します。
オープンガイドGo HTTP サーバー構造化ロギング
ルート エラー率、レイテンシー パーセンタイル、リリース比較のために、型指定されたリクエスト結果イベントを Go HTTP サービスに追加します。
オープンガイドRails の Ruby 構造化イベント分析
安全でクエリ可能なフィールドを使用して、Telemetry の HTTP API を通じて Rails コントローラーとバックグラウンド ワークフローの結果を記録します。
オープンガイド