> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ja/serufuhosuto/enterprise/deployment-manager/services/event-store.md).

# Event Store

Event Store は、デバイス上の推論パイプラインによって生成されたイベントを記録するエッジコンテナサービスです。検査結果、品質チェック、安全アラート、その他の Workflow の出力をローカルに保持し、REST API 経由で返し、独自にディスク使用量を管理するため、デバイスがいっぱいになることはありません。

Event Store に書き込まれたイベントは、Roboflow に次の形式でもバックアップできます。 [Vision Events](/deployment/ja/to/vision-events.md) 長期保存と分析のために。

{% hint style="info" %}
Event Store は Enterprise 顧客限定で利用できます。 [Roboflow の営業チームにお問い合わせください](https://roboflow.com/sales) 詳細をご確認ください。
{% endhint %}

## 接続詳細

置き換えてください `<device-ip>` を Deployment Manager のデバイスページに表示されている IP アドレスに。

<table data-search="false"><thead><tr><th>用途</th><th>アドレス</th></tr></thead><tbody><tr><td>REST API</td><td><code>http://&#x3C;device-ip>:8001</code></td></tr><tr><td>対話型 Swagger ドキュメント</td><td><code>http://&#x3C;device-ip>:8001/docs</code></td></tr></tbody></table>

ポート 8001 は両方を HTTP で提供します。参照: [Event Store REST API](/deployment/ja/serufuhosuto/enterprise/deployment-manager/services/event-store/rest-api.md) エンドポイントリファレンスをご覧ください。

API を呼び出さずにデバイスのリアルタイム容量と使用履歴を確認するには、次を使用します。 [Event Store のステータスを表示](/deployment/ja/serufuhosuto/enterprise/deployment-manager/monitoring/view-event-store-status.md).

## ストレージ設定

これらはデバイスの Configuration タブにある Event Store カードから設定します。各項目はサービス上の環境変数に対応しています。

<table data-search="false"><thead><tr><th>設定</th><th>変数</th><th>デフォルト</th><th>説明</th></tr></thead><tbody><tr><td>「保持日数」</td><td><code>RETENTION_DAYS</code></td><td><code>1</code></td><td>これより古いイベントは削除されます。</td></tr><tr><td>「最大レコード数」</td><td><code>MAX_RECORDS</code></td><td><code>1000000</code></td><td>保持されるイベントの最大数です。これを超えると最も古いものから削除されます。</td></tr><tr><td>「最大レコードサイズ」</td><td><code>MAX_RECORD_SIZE_BYTES</code></td><td><code>524288</code> (512 KB)</td><td>1件のイベントレコードの最大サイズです。これを超えるイベントは拒否されます。</td></tr><tr><td>「最大ストレージ」</td><td><code>MAX_STORAGE_BYTES</code></td><td><code>5368709120</code> (5 GB)</td><td>保存ファイルのディスク総容量上限です。使用量がこの上限に近づくと、クリーンアップでファイルが整理されます。</td></tr><tr><td>「クリーンアップ間隔」</td><td><code>CLEANUP_INTERVAL_SECONDS</code></td><td><code>300</code></td><td>自動クリーンアップの実行頻度です。</td></tr></tbody></table>

追加の変数:

<table data-search="false"><thead><tr><th>変数</th><th>デフォルト</th><th>説明</th></tr></thead><tbody><tr><td><code>PORT</code></td><td><code>8001</code></td><td>API 用の HTTP ポート。</td></tr><tr><td><code>DATA_DIR</code></td><td><code>/data</code></td><td>デバイス上のデータ保存ディレクトリ。</td></tr><tr><td><code>CONSISTENCY_CHECK_INTERVAL</code></td><td><code>12</code></td><td>N 回のクリーンアップごとに整合性チェックを実行します（デフォルトのクリーンアップ間隔ではおおむね 1 時間ごと）。</td></tr><tr><td><code>API_KEY</code></td><td>なし</td><td>任意の API キー。参照: <a href="#authentication">認証</a>.</td></tr></tbody></table>

## 自動クリーンアップ

クリーンアップは専用のバックグラウンドスレッドで実行されるため、API リクエストをブロックしません。各スケジュール実行では次の 3 ステップを順に行います:

1. 保持期間。次より古いレコードを削除します: `RETENTION_DAYS`.
2. レコード制限。レコード数が次を超える場合は `MAX_RECORDS`、制限を超えたレコードを削除します。まず既にアップロード済みのレコード、その後に最も古いものを削除します。
3. ストレージ制限。保存済みファイルが次に近づくと `MAX_STORAGE_BYTES`、画像ファイルを削除します。まず既にアップロード済みのファイル、その後に最も古いものを削除します。親レコードは保持され、その `current_file_count` は減算されます。

毎回 `CONSISTENCY_CHECK_INTERVAL` クリーンアップ時には、サービスはデータベースとファイルシステムの整合性も取ります。対応するデータベースレコードがないディスク上の孤立ファイルを、進行中の書き込みに触れないよう 10 分の猶予期間を設けて削除し、ファイルがすでに失われているぶら下がりデータベースレコードも削除します。

次でも即座に実行できます: `POST /admin/cleanup`。参照: [管理](/deployment/ja/serufuhosuto/enterprise/deployment-manager/services/event-store/rest-api.md#administration).

### 画像の一時性

API が返す画像 ID は本質的に短命です。1 分前には解決できた ID でも、クリーンアップ後には 404 になることがあります。これはストレージ制約のあるエッジハードウェアでは意図された動作です。

* 処理してください `404` 画像取得時のレスポンスを。
* 画像 ID は 1 セッションを超えてキャッシュしないでください。
* 比較してください `current_file_count` を `original_file_count` イベントの original\_file\_count と比較して、そのファイルがクリーンアップされたかどうかを判断します。

## 下書きイベントと動画

パイプラインはイベントをすぐに保存し、エンコード完了後に数秒遅れて動画を添付できます。イベントは次のように作成します: `draft: true`、動画の準備ができたらアップロードし、その後イベントを確定します。次を付けずに作成されたイベントは `draft` 作成時に確定されるため、既存のパイプラインには影響しません。

イベントが確定されるまでは、クラウドアップロードの対象外です。またクリーンアップからも保護されますが、それはサービスでクラウドアップロードが有効な間のみです。クラウドアップロードがオフの場合、下書きは他のレコードと同様に削除可能です。

<table data-search="false"><thead><tr><th>設定</th><th>変数</th><th>デフォルト</th><th>説明</th></tr></thead><tbody><tr><td>「下書きを自動確定するまでの時間」</td><td><code>DRAFT_AUTO_FINALIZE_SECONDS</code></td><td><code>3600</code></td><td>動画が届かない下書きは、この秒数が経過すると強制的に確定され、バックアップとクリーンアップの対象になります。</td></tr><tr><td>「最大動画アップロードサイズ」</td><td><code>MAX_VIDEO_UPLOAD_BYTES</code></td><td><code>1073741824</code> (1 GB)</td><td>イベントに添付できる 1 本あたりの最大動画サイズです。</td></tr></tbody></table>

{% hint style="warning" %}
設定 `DRAFT_AUTO_FINALIZE_SECONDS` に `0` にするとスイープが無効になります。finalize を呼ばないプロデューサーの下書きが蓄積し、クラウドバックアップがオンの場合、ストアがいっぱいになって新しい書き込みが HTTP 529 でブロックされ、ストアをリセットするまで解消されません。
{% endhint %}

## 画像ごとのメタデータとローカル専用ファイル

パイプラインは、デバイス上に残りクラウドには一切アップロードされない追加データをイベントに添付できます。

画像ごとのメタデータは、判定、シリアル番号、角度ラベルなどを含む、個々の画像に添付される小さな単層のキー/値データオブジェクトです。レコードとともに保存され API から返されますが、検索はできず、バックアップの対象外です。 `METADATA_MAX_VALUE_LENGTH` （デフォルト `1000`）で文字列値の長さに上限を設けます。

ローカル専用ファイルは、検査データの塊、サムネイル、JSON など、イベントに添付される任意のファイルです。content-type の制限はなく、 `MAX_LOCAL_ONLY_FILE_UPLOAD_BYTES` （デフォルト `104857600`（既定では 100 MB）で各アップロードの上限が決まります。ファイルはイベントがまだ下書きの間しか添付できないため、パイプラインは次のようにイベントを作成する必要があります: `draft: true`、ファイルを添付し、その後確定します。

どちらも詳細は次に説明されています: [REST API リファレンス](/deployment/ja/serufuhosuto/enterprise/deployment-manager/services/event-store/rest-api.md).

## クラウドバックアップ

デバイスで Vision Events のバックアップが有効な場合、確定済みイベントは Roboflow にアップロードされます。次の 2 つのモードがあります:

* Records and Files は、イベントメタデータを関連する画像ファイルとともにアップロードします。
* Records Only はイベントメタデータのみをアップロードし、画像はデバイスに残すため、帯域幅の使用量が少なくなります。

画像ごとのメタデータとローカル専用ファイルは、どちらのモードでもアップロードされません。

参照: [イベントを送信](/deployment/ja/to/vision-events/send-events.md) バックアップを有効にし、Roboflow で結果を確認する方法。

### アップロードの信頼性

失敗したアップロードは再試行されます。「アップロード放棄ポリシー」は、サーバーが拒否し続けるレコードをどう扱うかを制御します。

<table data-search="false"><thead><tr><th>ポリシー</th><th>変数値</th><th>動作</th></tr></thead><tbody><tr><td>決して放棄しない</td><td><code>NEVER_ABANDON</code> （デフォルト）</td><td>レコードは成功するまで無期限に再試行されます。データ保全には最も安全ですが、滞留レコードで埋まったデバイスは、未アップロードのものを破棄する代わりに、新しい書き込みを HTTP 529 で拒否し始めます。</td></tr><tr><td>最大試行回数後に放棄</td><td><code>ABANDON_AFTER_MAX_ATTEMPTS</code></td><td>後 <code>UPLOAD_MAX_ATTEMPTS</code> 回の content-error 試行後（デフォルト <code>10</code>）にレコードは放棄済みとしてマークされ、ストレージクリーンアップの優先対象になります。継続的に失敗するレコードを失うほうが新しい書き込みを止めるよりよい場合に使用してください。</td></tr></tbody></table>

サーバーからの content 系の 4xx 応答（例: 400、413、422）のみが試行カウンターを進めます。すべての 5xx 応答、タイムアウト、ネットワークエラー、および 401、403、404、408、429 は一時的なものとして扱われ、ポリシーに関係なく再試行されます。

`MIN_UPLOAD_IMAGE_BYTES` （デフォルト `1`）で、指定サイズより小さい画像をアップロード前にスキップします。現在、破損しているが空ではない画像はサーバーから 5xx として返るため、どちらのポリシーでも無期限に再試行されます。この値を一般的な破損サイズより大きくするのが回避策です。

## 認証

API キー認証は任意で、デフォルトでは無効です。次を設定すると `API_KEY` サービス上で有効になります。その後は、次を除くすべてのエンドポイントで `/health` が必要です: `X-API-Key` ヘッダー。

```yaml
環境:
  - API_KEY=your-secret-api-key-here
```

```bash
curl -H "X-API-Key: your-secret-api-key-here" \\
  http://<device-ip>:8001/v2/events/latest/query
```

`/health` 認証なしでも引き続き到達可能なため、監視システムやロードバランサーがポーリングできます。