Inngest and Trigger.dev job telemetry でイベントを送信して確認する
制御されたアプリケーション境界で Inngest and Trigger.dev job telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
バックグラウンドジョブの監視
- 2
契約を定義する
プロバイダー、job_name、run_id、queue_name、および trigger_type
- 3
結果で発行する
試行レベルの分析が必要な場合にのみ試行イベントを発行し、再試行によって完了したジョブの数が増大しないように、1 つの別個の終了イベントを発行します。
- 4
証拠を検証する
Exercise a known fixture, then inspect job_completed for one correctly typed terminal row.
始める前に
始める前に
- 安定した関数、タスク、実行識別子を持つ Ingest 関数または Trigger.dev タスク
- 成功、再試行の完了、およびキャンセルを監視するライフサイクル フックまたはターミナル ハンドラー
- 冪等の副作用と試行と最終的な実行結果の間の明示的な区別
配信設定
サーバー側のインストールと初期化
サーバー専用コードで telemetry-sh をインポートし、process.env.TELEMETRY_API_KEY で一度初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
npmのインストール
npm install telemetry-sh- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
Inngest and Trigger.dev job telemetryイベント
await telemetry.log("job_completed", {
provider: "inngest",
job_name: "sync_stripe_subscription",
run_id: runId,
queue_name: "billing",
attempt: 1,
status: "success",
duration_ms: 4120,
item_count: 37,
retry_exhausted: false,
release: process.env.APP_RELEASE,
});イベントスキーマ
プロバイダー、job_name、run_id、queue_name、および trigger_type
試行、ステータス、duration_ms、scheduled_at、started_at、および error_type
item_count、retry_exhausted、idempotency_outcome、およびリリース
設定を確認する
チェックポイント 1
試行レベルの分析が必要な場合にのみ試行イベントを発行し、再試行によって完了したジョブの数が増大しないように、1 つの別個の終了イベントを発行します。
チェックポイント 2
再試行が完了した場合は、プロバイダーのライフサイクルまたは失敗フックを使用します。キャッチされたステップ エラーは、必ずしも失敗した関数またはタスクであるとは限りません。
チェックポイント 3
監視によって重複した副作用が隠蔽されないように、冪等フィクスチャを使用してリプレイと再試行の動作をテストします。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
Inngest and Trigger.dev job telemetry 検証クエリ
SELECT *
FROM job_completed
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
イベントを記録する場所
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの例
このワークフローのイベントスキーマ
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
その他のSQL例
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
相関のあるワークフローのタイムラインを再構築する
最近失敗したワークフロー中に、順番に何が起こったのでしょうか?
レシピを開くバックグラウンドジョブの再試行と失敗率を測定する
どのバックグラウンド ジョブが再試行を最も多く消費するか、または依然として失敗するのはどれですか?
レシピを開くSQL で停止したバックグラウンド ジョブを見つける
開始されたが、最終イベントを生成しなかったジョブはどれですか?
レシピを開くジョブごとのキュー待ち時間の測定
ワーカーが開始するまでに最も長く待機するジョブはどれですか?
レシピを開く配信不能キューの増加を測定する
デッドレター ジョブを解決するよりも早く追加しているキューはどれですか?
レシピを開く欠落した Cron スケジュールの検出
スケジュールされたジョブは、文書化された間隔よりも遅く実行されましたか?
レシピを開くバックグラウンドジョブの再試行ストームを検出する
現在、再試行に最も多くの時間を費やしている職種はどれですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合