n8n workflow telemetry でイベントを送信して確認する
制御されたアプリケーション境界で n8n workflow telemetry を使用し、イベント コントラクトを小さく保ち、集約ビューを構築する前に既知の結果を検証します。
- 1
結果を選択してください
ワークフローの完了監視
- 2
契約を定義する
execution_id、workflow_name、workflow_version、trigger_type、schedule_name、およびリリース
- 3
結果で発行する
POST https://api.telemetry.sh/log を手動で設定し、Send Body を有効にして JSON を選びます。このスニペットは設定の概要であり、インポート可能な n8n ワークフローではありません。保存した Header Auth 認証情報は別途選択してください。
- 4
証拠を検証する
Exercise a known fixture, then inspect n8n_workflow_completed for one correctly typed terminal row.
始める前に
始める前に
- n8n HTTP リクエスト ノードが明示的な成功またはエラー ブランチに配置されました
- HTTP Request で Authentication: Generic Credential Type を選び、Generic Auth Type: Header Auth を選択します。Name を Authorization、Value を Telemetry API キーにした認証情報を保存します。Bearer 接頭辞は付けません。
- 承認されたワークフローメタデータと制限された結果フィールドのみを準備する Set ノード
配信設定
サーバー側のインストールと初期化
文書化された JSON シェイプを、サーバー側キーと制限された HTTP タイムアウトとともにログ API に送信します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。
- 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
- 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
- 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。
スニペット
1 つの構造化されたイベントから始める
ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。
n8n workflow telemetryイベント
{
"method": "POST",
"url": "https://api.telemetry.sh/log",
"timeout_ms": 2000,
"body": {
"table": "n8n_workflow_completed",
"data": {
"execution_id": "={{ $json.execution_id }}",
"workflow_name": "={{ $json.workflow_name }}",
"workflow_version": "={{ $json.workflow_version }}",
"trigger_type": "={{ $json.trigger_type }}",
"status": "={{ $json.status }}",
"duration_ms": "={{ $json.duration_ms }}",
"retry_count": "={{ $json.retry_count }}",
"item_count": "={{ $json.item_count }}",
"error_type": "={{ $json.error_type }}",
"release": "={{ $json.release }}"
}
}
}イベントスキーマ
execution_id、workflow_name、workflow_version、trigger_type、schedule_name、およびリリース
ステータス、duration_ms、retry_count、item_count、failed_step、および error_type
account_id、integration_name、delivery_status、承認時の環境、地域
設定を確認する
チェックポイント 1
POST https://api.telemetry.sh/log を手動で設定し、Send Body を有効にして JSON を選びます。このスニペットは設定の概要であり、インポート可能な n8n ワークフローではありません。保存した Header Auth 認証情報は別途選択してください。
チェックポイント 2
上流のノードで承認済みのフィールドを準備します。所要時間、項目数、再試行回数は数値文字列ではなく数値にしてください。アプリケーションのイベントを送信する前に、使用中の n8n バージョンで実際のリクエスト本文を検証してください。
チェックポイント 3
HTTP 要求ノードが中間ノードの結果ではなく最終的なワークフロー結果を受け取るように、明示的な成功分岐とエラー分岐を個別に使用します。
チェックポイント 4
可観測性の配信が自動化の結果に影響を与えることが許可されているかどうかに応じて、制限されたタイムアウトと失敗時の続行を構成します。
チェックポイント 5
ソース項目の本文、認証情報、トークン、プライベート データを含む式、任意のエラー メッセージ、または完全な n8n 実行データを送信しないでください。
検証
イベントが到着したことを証明する
既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。
n8n workflow telemetry 検証クエリ
SELECT *
FROM n8n_workflow_completed
ORDER BY timestamp_utc DESC
LIMIT 20;実装の参考資料
新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。
イベントを記録する場所
結果イベントを小さく、回復可能なものに保つ
このパターンが提供するのは、
- 上流のワークフローの横にある、制限付きの SQL 対応の結果。
- ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
- 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。
このパターンでは提供されません
- OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
- ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
- 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。
イベントスキーマの例
このワークフローのイベントスキーマ
クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。
関連製品の機能
このワークフローを続行します アラート
レビューされた信頼性クエリを、所有するしきい値と応答のワークフローにプロモートします。
関連する SQL レシピ
その他のSQL例
このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。
相関のあるワークフローのタイムラインを再構築する
最近失敗したワークフロー中に、順番に何が起こったのでしょうか?
レシピを開くバックグラウンドジョブの再試行と失敗率を測定する
どのバックグラウンド ジョブが再試行を最も多く消費するか、または依然として失敗するのはどれですか?
レシピを開くSQL で停止したバックグラウンド ジョブを見つける
開始されたが、最終イベントを生成しなかったジョブはどれですか?
レシピを開く欠落しているサービスのハートビートを検出する
ハートビートの送信を停止したと予想されるテレメトリ ソースはどれですか?
レシピを開く実装ファミリーごとに参照する
関連する統合パターンを比較する
この統合と組み合わせるテンプレート
さらなる統合