> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise-docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# データプッシュ

データプッシュ設定は、OpenTelemetry (OTel) オープンソース標準に基づいて構築されたエンタープライズレベルのデータガバナンスモジュールの中核機能であり、企業のデータサイロ問題を解決することを目的としています。標準化されたデータパイプラインを通じて、システム管理者はプラットフォームの詳細なビジネスデータ（アプリケーション実行指標、トークン消費、ユーザー行動などを含む）を企業の自社BIシステムやデータウェアハウスにリアルタイムでプッシュし、統一されたデータ資産の蓄積、精緻な運用分析、および全体的なビジネス洞察を実現できます。

## 1. 機能紹介

エンタープライズ利用シナリオでは、Difyプラットフォームのビジネスデータは各ワークスペースやアプリケーション内に分散しており、企業の自社データシステムに統一して集約することが難しく、以下の課題が生じています：

* **データサイロ**：ワークスペースを跨いだアプリケーションの実行、トークン消費、ユーザー行動の全体的な分析ができない。
* **統合コストが高い**：標準化されたデータ出力メカニズムが不足しており、企業は独自のデータ収集ソリューションを開発する必要がある。
* **プライバシーリスク**：データプッシュプロセスにおいて機密コンテンツの制御性が不足しており、コンプライアンス問題を引き起こしやすい。

### 1.1 機能の価値

* **標準化された互換性**：OpenTelemetryプロトコルに基づいており、企業の既存の監視システム、データウェアハウス、またはBIプラットフォームと連携します。
* **全リンクデータのカバレッジ**：詳細なビジネスデータをプッシュし、ユーザー、アプリケーション、ワークスペースなどの多次元分析をサポートします。
* **高信頼性の保証**：バッファメカニズムを通じてネットワークの変動に対応し、主要業務への影響がないことを優先的に保証します。
* **プライバシー制御**：Input/Outputなどの機密コンテンツをプッシュするかどうかを制御するスイッチを提供し、コンプライアンス要件を満たします。
* **リアルタイムプッシュ**：データをリアルタイムで送信し、企業がタイムリーに運用レビューや異常対応を行うことをサポートします。

### 1.2 適用シナリオ

* **全体的な運用分析**：Difyプラットフォームのアプリケーション実行データを自社BIシステムに同期し、部門横断的な評価を行います。
* **コストの精緻な計算**：ワークスペース/アプリケーション/ユーザーの次元でトークン消費を統計し、コスト配分と最適化を行います。
* **パフォーマンス監視とトラブルシューティング**：リクエストの所要時間、失敗率などの指標を監視し、問題を迅速に特定します。
* **コンプライアンスデータ管理**：機密データの出力を厳格に制御し、機密でない統計次元のデータのみをプッシュします。

### 1.3 コア概念

**データ転送と標準**

* **データプッシュ**：Difyプラットフォームで生成された実行ログ、監視指標などのデータを、OTel標準プロトコルを通じて外部システムのサービスにリアルタイムで転送します。

* **OpenTelemetry (OTel)**：テレメトリデータ（メトリクス、ログ、トレース）の生成、収集、管理、エクスポートに使用されるオープンソース標準です。

* **統合エンドポイント**：MetricsとTracesデータを同時に同じエンドポイントにプッシュします。

* **分離エンドポイント**：MetricsとTracesデータをそれぞれ同じ、または異なるエンドポイントにプッシュします。

**実行と制御メカニズム**

* **バッファ (Buffer)**：プッシュサービスと受信側の間の一時的なストレージキュー（FIFO）であり、ネットワークのジッターや受信側の処理遅延に対応するために使用されます。バッファが満杯の場合、主要業務を保護するために新しいデータが破棄されます。
* **プライバシー制御スイッチ**：Input/Outputの具体的な内容をプッシュするかどうかを制御します。オフにした場合、Message IDなどのメタデータのみがプッシュされ、企業は内容を自ら確認する必要があります。

### 1.4 データ辞書

データプッシュ機能の詳細なデータフィールド定義、指標の説明、およびログ形式については、[データプッシュデータ辞書](/ja/3.10.x/administer/data-push-data-dictionary)。を参照してください。

## 2. 操作説明

### 2.0 クイックスタート

データプッシュの典型的な設定フローには以下が含まれます：**設定ページに入る > OTelパラメータを入力 > 接続性をテスト > 設定を保存 > プッシュサービスを開始**。

1. **設定ページに入る**
   エンタープライズ管理画面にログインし、【データガバナンス】>【データプッシュ設定】に入ります。
2. **OTelパラメータを入力**
   サービスが未接続の場合、右上の【パラメータ設定】をクリックしてOpenTelemetry Collector情報を入力します。
3. **テストと保存**
   【接続性をテスト】をクリックしてネットワークと設定の有効性を検証し、問題がないことを確認した後、設定を保存し、サービスの再起動を確認します。
4. **サービスを開始**
   メインページに戻り、【接続してデータをプッシュ】をクリックしてサービスを開始します。

### 2.1 サービス実行状態の確認

【データプッシュ設定】ページに入ると、デフォルトでサービスのリアルタイム実行状態が表示されます。

**状態 1：サービス未実行**

* ページ提示：「未接続、パラメータを設定して接続を開始してください」。
* 右側の【接続してデータをプッシュ】ボタンをクリックして接続を開始するか、右上の【パラメータ設定】をクリックして設定フローに入ります。

**状態 2：サービス実行中（接続済み）**
ページには以下の重要な情報が表示されます：

* **状態表示**：緑色のインジケーター + 「サービス実行中」。
* **接続情報**：今回の接続開始時間（YYYY-MM-DD HH:mm:ss）。
* **データ統計**：プッシュ済みデータ量（リアルタイム更新、単位：MB/GB）、未プッシュの滞留データ量（バッファの一時保存データ）。
* **サービスログ**：OpenTelemetryからフィードバックされた異常ログ、ネットワーク異常ログなどを表示します。

**状態 3：サービス実行異常（接続済み）**

* **状態表示**：オレンジ色のインジケーター + 「サービス実行異常」。

> **異常処理メカニズムの説明：**
>
> * プッシュは非同期メカニズムを採用しており、**主要業務リンクに影響を与えません**。
> * プッシュ失敗または接続中断時、データは自動的にバッファに保存され、接続回復後にプッシュを継続します。
> * バッファがいっぱいになると、コアユーザーインタラクションのブロックを回避するために、最新のデータが最初に破棄されます。
> * *注意：ページにはデータ損失につながる可能性のあるシナリオ（プッシュサービスの異常、下流の消費遅延によるバッファオーバーフロー、システム再起動など）が提示されます。*

### 2.2 パラメータ設定

【パラメータ設定】をクリックすると設定フォームがポップアップし、以下の設定を完了します：

**1. 必須設定項目**

* **Endpoint URL**：OpenTelemetry Collectorのエンドポイントアドレス（例：`http://otel-collector:4318`）。Difyサーバーからアクセス可能であることを確認してください。
* **Transport Protocol**（転送プロトコル）：
  * **http/protobuf**（推奨デフォルト値）
  * **grpc**（パフォーマンスが高く、企業内部の安定したネットワークに適しています）
  * **http/json**（デバッグ用のみ、パフォーマンスは低い）
* **Compression**（圧縮方式）：
  * **gzip**（推奨デフォルト値）
  * **none**（デバッグ用のみ）

**2. オプション設定項目**

* **Timeout**：プッシュタイムアウト時間、デフォルトは5秒。
* **Headers**：認証などに使用されるカスタムリクエストヘッダー（例：`Authorization: Bearer <token>`）、複数行入力に対応。
* **TLS安全接続を有効にする**：有効にした後、証明書ファイル（Certificate File (CA)、Client Key File、Client Certificate File）をアップロードする必要があります。**本番環境では有効にすることを推奨します**。

**3. 設定操作**

* **接続性をテスト**：接続検証を行い、成功/失敗の理由（ネットワーク不通、証明書無効など）を提示します。
* **設定を保存**：確認ボックス「アプリケーション設定を保存してサービスを再起動しますか？」がポップアップします。確認後、保存して実行状態ページに戻ります。

### 2.3 プライバシー制御設定

【データプッシュ設定】ページのプライバシー制御エリアで、以下を設定できます：

* **Input/Output内容のプッシュ（スイッチ）**：
  * **オン**：リクエストのInput内容とモデルのOutput内容をプッシュします。
  * **オフ**：Message ID、ユーザーID、アプリIDなどのメタデータのみをプッシュし、具体的な内容は含みません。
* 変更後、【設定を保存】をクリックして有効にします。

### 2.4 プッシュサービスの開始と停止

* **サービスを開始**：未接続状態で【接続してデータをプッシュ】をクリックすると、状態が「サービス実行中」に変わります。
* **サービスを停止**：実行中状態で【プッシュを停止】をクリックし、確認後に停止すると、状態が「未接続」に変わります。

## 3. トラブルシューティング

* **OpenTelemetry Collectorに接続できない**：Endpoint URLが正しいか、ネットワークが通じているかを確認してください。TLSを有効にしている場合、CA/クライアント証明書/秘密鍵の有効性と形式を確認してください。【接続性をテスト】を使用して具体的なエラーを確認し、設定を修正してください。
* **データプッシュの中断**：実行ログを確認し、ネットワークの変動やCollectorの異常を調査してください。Collectorが正常に動作しているか、受信上限に達していないかを確認してください。
* **データ滞留が増え続ける**：通常、Collectorの消費速度が不足しているか、ネットワーク遅延が原因です。Collectorのリソース設定を最適化するか、インスタンスを拡張することを推奨します。
* **設定の保存に失敗**：必須項目が完全に入力されているか確認してください。TLSを有効にしている場合、関連する証明書ファイルが正しくアップロードされているか確認してください。
* **データ損失**：サービス異常、バッファオーバーフロー、またはシステム再起動時に発生する可能性があります（これは主要業務を保護するためのダウングレード戦略です）。重要なデータを失うことができない場合は、Collectorの処理能力を向上させ、長期的な滞留を避けることを推奨します。

## 4. よくある質問 (FAQ)

### データプッシュはDifyプラットフォームの主要業務のパフォーマンスに影響しますか？

いいえ。データプッシュは非同期メカニズムを採用しており、主要業務リンクから隔離されています。バッファが満杯の場合、新しいデータは破棄され、ユーザーインタラクションやアプリケーションの実行をブロックすることはありません。

### データプッシュにはどのような内容が含まれますか？

詳細な情報をカバーしています（以下は例です）：

* **メタデータ**：Message ID、ユーザーID、アプリID、ワークスペースID、タイムスタンプ。
* **実行指標**：トークン消費（入力/出力）、リクエスト所要時間（RT）、実行状態（成功/失敗）。
* **ユーザー行動**：いいね/よくないねのフィードバック。
  *(注：プライバシー制御スイッチを通じて、Input/Outputの具体的な内容をプッシュするかどうかを決定できます)*。

### なぜデータ滞留が発生するのですか？

通常、Collectorの処理速度がデータ生成速度よりも遅いか、ネットワーク遅延が原因です。滞留したデータはバッファに入り、接続回復後にプッシュを継続します。バッファが満杯の場合、新しいデータは破棄されます。

### 本番環境の推奨設定は何ですか？

転送プロトコルには `http/protobuf` または `grpc` を使用し、圧縮方式には `gzip` を選択することを推奨します。TLS安全接続を有効にし、認証Headersを設定することを推奨します。コンプライアンス要件がある場合は、Input/Output内容のプッシュをオフにすることを推奨します。

## 5. ベストプラクティス

* **セキュリティとコンプライアンス優先**：本番環境ではTLSを有効にし、認証Headersを設定することを強く推奨します。データプライバシーに対する厳格な要件があるシナリオでは、必ずInput/Output内容のプッシュをオフにしてください。
* **リアルタイム監視とアラート**：管理画面の実行状態とログを定期的に確認してください。企業Collector側で監視アラート（接続中断、データ滞留がしきい値を超えるなど）を設定し、タイムリーに介入できるようにすることを推奨します。
* **パフォーマンスチューニング**：大規模な高同時実行シナリオでは、`grpc` プロトコルを優先的に使用してください。同時に、下流のCollectorリソースが十分であることを確認し、消費不足によるプラットフォーム側のバッファオーバーフローとデータ損失を回避してください。