n8nの実行ログを管理する｜失敗の追跡と秘密情報の削除を両立する

n8nのログは、失敗を追える記録と、保存しなくてよい本文・秘密情報を分けて設計します。実行データ、サーバーのログ、外部サービスの結果記録は、同じ目的の記録ではありません。

調べたい問題に合わせて、記録の場所を選ぶ

同じ依頼IDをこれらの記録へ対応させると、失敗した画面だけでなく、外部で完了した範囲も追えます。

debugの詳細度を、常時保存の量にしない

セルフホストではログの詳細度や出力先を設定できます。たとえばN8N_LOG_LEVELで詳細度を選びます。選べる設定は公式のLoggingで確認してください。

調査のために詳細度を増やした場合は、確認後に元へ戻し、増えた記録の保管範囲も点検します。ログファイルの世代管理と、workflowの実行データの保持は別の設定として確認します。

本文を残す前に、IDで追えるか考える

残す記録の設計例
request_id：対象の依頼
execution_id：n8nの実行
node：失敗した処理
status：failed / done / needs_review
external_result_id：照合に必要な結果ID
error_summary：秘密を除いた要約

APIキー、認証ヘッダー、パスワードは記録へ出さないようにします。顧客本文や添付を残す場合は、見られる担当、保存期間、削除方法を決めます。共有する障害報告は、原ログをそのまま貼るより、必要な証拠を伏せてまとめます。

削除後も復旧に必要な記録が残るか確認する

実行データを整理しても、処理済みIDと外部結果IDの対応が必要な場合があります。保存期間が過ぎた後に再送された依頼を、未処理と判断しない仕組みも考えます。

まず一つの失敗を、入力本文を共有せずに説明できるか試してください。結果不明の処理は二重実行の照合へつなげ、調査の便利さだけで保存量を増やさないようにします。