> 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/hi/self-hosted/enterprise/deployment-manager/services/event-store.md).

# Event Store

automatic retention, storage limits, और वैकल्पिक cloud backup के साथ edge device पर inference events संग्रहीत करें।

इवेंट स्टोर एक एज कंटेनर सेवा है जो डिवाइस पर इन्फरेंस पाइपलाइनों द्वारा उत्पन्न इवेंट्स को रिकॉर्ड करती है। यह निरीक्षण परिणाम, गुणवत्ता जाँच, सुरक्षा अलर्ट और अन्य Workflow आउटपुट स्थानीय रूप से रखती है, उन्हें REST API के माध्यम से वापस परोसती है, और अपनी डिस्क उपयोगिता स्वयं प्रबंधित करती है ताकि डिवाइस कभी भर न जाए।

इवेंट स्टोर में लिखे गए इवेंट्स का बैकअप Roboflow पर भी लिया जा सकता है [विज़न इवेंट्स](/deployment/hi/monitoring-and-analytics/vision-events.md) दीर्घकालिक संग्रहण और विश्लेषण के लिए।

{% hint style="info" %}
Event Store केवल Enterprise ग्राहकों के लिए उपलब्ध है। [अधिक जानकारी के लिए Roboflow बिक्री टीम से संपर्क करें](https://roboflow.com/sales) ।
{% endhint %}

## कनेक्शन विवरण

बदलें `<device-ip>` Deployment Manager में डिवाइस पेज पर दिखाई गई IP address के साथ।

<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/hi/self-hosted/enterprise/deployment-manager/services/event-store/rest-api.md) एंडपॉइंट संदर्भ के लिए।

API को कॉल किए बिना किसी डिवाइस की लाइव क्षमता और उपयोग इतिहास देखने के लिए, उपयोग करें [Event Store स्थिति देखें](/deployment/hi/self-hosted/enterprise/deployment-manager/monitoring/view-event-store-status.md).

## संग्रहण सेटिंग्स

इन्हें डिवाइस के Configuration टैब पर Event Store कार्ड से कॉन्फ़िगर करें। प्रत्येक सेवा पर एक environment variable से मैप होता है।

<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>एकल इवेंट रिकॉर्ड का अधिकतम आकार। बड़े इवेंट्स अस्वीकार कर दिए जाते हैं।</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 क्लीनअप पर एक संगतता जाँच चलाएँ (डिफ़ॉल्ट क्लीनअप अंतराल पर लगभग प्रति घंटा)।</td></tr><tr><td><code>API_KEY</code></td><td>कोई नहीं</td><td>वैकल्पिक API कुंजी। देखें <a href="#authentication">प्रमाणीकरण</a>.</td></tr></tbody></table>

## स्वचालित क्लीनअप

क्लीनअप एक समर्पित बैकग्राउंड थ्रेड पर चलता है, इसलिए यह कभी भी API अनुरोधों को ब्लॉक नहीं करता। प्रत्येक निर्धारित पास क्रम से तीन चरण चलाता है:

1. रिटेंशन। इससे पुराने रिकॉर्ड हटाएँ `RETENTION_DAYS`.
2. रिकॉर्ड सीमा। यदि रिकॉर्ड संख्या इससे अधिक हो जाए `MAX_RECORDS`तो सीमा से अधिक रिकॉर्ड हटाएँ, पहले वे जो पहले ही अपलोड हो चुके हैं, फिर सबसे पुराने।
3. संग्रहण सीमा। जैसे-जैसे संग्रहीत फ़ाइलें `MAX_STORAGE_BYTES`के करीब पहुँचती हैं, छवि फ़ाइलें हटाएँ, पहले वे जो पहले ही अपलोड हो चुकी हैं, फिर सबसे पुरानी। मूल रिकॉर्ड सुरक्षित रहता है और उसका `current_file_count` कम किया जाता है।

हर `CONSISTENCY_CHECK_INTERVAL` क्लीनअप पर सेवा डेटाबेस को फ़ाइलसिस्टम के साथ भी समेटती है। यह डिस्क पर मौजूद अनाथ फ़ाइलें हटाती है जिनका कोई मेल खाता डेटाबेस रिकॉर्ड नहीं होता, 10 मिनट की ग्रेस अवधि का उपयोग करते हुए ताकि चल रहे writes को न छेड़ा जाए, और उन लटके हुए डेटाबेस रिकॉर्ड्स को हटाती है जिनकी फ़ाइल पहले ही गायब हो चुकी है।

आप इसके साथ तुरंत एक पास भी ट्रिगर कर सकते हैं `POST /admin/cleanup`. देखें [प्रशासन](/deployment/hi/self-hosted/enterprise/deployment-manager/services/event-store/rest-api.md#administration).

### छवि अस्थायित्व

API द्वारा लौटाए गए छवि ID स्वभावतः अल्पकालिक होते हैं। जो ID एक मिनट पहले रिज़ॉल्व हुई थी, वह cleanup pass के बाद 404 दे सकती है, और यह storage-constrained edge hardware पर डिज़ाइन के अनुसार है।

* संभालें `404` छवियाँ प्राप्त करते समय प्रतिक्रियाएँ।
* एकल सत्र से आगे छवि ID कैश न करें।
* तुलना करें `current_file_count` से `original_file_count` किसी इवेंट पर यह जानने के लिए कि उसकी फ़ाइलें साफ़ की गई थीं या नहीं।

## ड्राफ्ट इवेंट्स और वीडियो

एक पाइपलाइन इवेंट को तुरंत सेव कर सकती है और एन्कोडिंग पूरी होने के कुछ सेकंड बाद वीडियो संलग्न कर सकती है। इवेंट बनाएं `draft: true` , वीडियो तैयार होने पर अपलोड करें, फिर इवेंट को अंतिम रूप दें। इवेंट्स जो बिना बनाए गए `draft` के बनाए जाते हैं, वे निर्माण के समय ही अंतिम हो जाते हैं, इसलिए मौजूदा पाइपलाइनों पर कोई असर नहीं पड़ता।

जब तक कोई इवेंट अंतिम नहीं हो जाता, वह cloud upload से छोड़ दिया जाता है। यह क्लीनअप से भी सुरक्षित रहता है, लेकिन केवल तब जब सेवा पर cloud upload सक्षम हो; cloud upload बंद होने पर, ड्राफ्ट किसी भी अन्य रिकॉर्ड की तरह हटाया जा सकता है।

<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>"अधिकतम वीडियो अपलोड आकार (MB)"</td><td><code>MAX_VIDEO_UPLOAD_BYTES</code></td><td><code>1073741824</code> (1 GB, app में दर्ज किया गया <code>1024</code> ऐप में)</td><td>डिवाइस पर किसी इवेंट से जोड़ा जा सकने वाला सबसे बड़ा एकल वीडियो। वैरिएबल bytes में है; app फ़ील्ड MB में है।</td></tr></tbody></table>

{% hint style="warning" %}
सेटिंग `DRAFT_AUTO_FINALIZE_SECONDS` को `0` सweep को निष्क्रिय करता है। तब ऐसे producer के ड्राफ्ट जो कभी finalize नहीं करते, जमा होते रहते हैं और cloud backup चालू होने पर store भर सकते हैं तथा store reset होने तक HTTP 529 के साथ नए writes को रोक सकते हैं।
{% endhint %}

## प्रति-छवि मेटाडेटा और केवल-स्थानीय फ़ाइलें

पाइपलाइनें किसी इवेंट में उसकी छवियों और पूर्वानुमानों से परे अतिरिक्त डेटा जोड़ सकती हैं।

प्रति-छवि मेटाडेटा key/value डेटा का एक छोटा, एक-स्तरीय ऑब्जेक्ट है जो किसी व्यक्तिगत छवि से जुड़ा होता है, जैसे निर्णय, सीरियल नंबर, या कोण लेबल। इसे रिकॉर्ड के साथ संग्रहीत किया जाता है और API द्वारा लौटाया जाता है, लेकिन यह query करने योग्य नहीं होता। "Records and Files" बैकअप के साथ, यह प्रत्येक छवि के साथ अपलोड होता है। `METADATA_MAX_VALUE_LENGTH` (डिफ़ॉल्ट `1000`) किसी string value की लंबाई सीमित करता है।

केवल-स्थानीय फ़ाइलें किसी इवेंट से जुड़ी मनमानी फ़ाइलें होती हैं, जैसे inspection blobs, thumbnails, या JSON। वे डिवाइस पर ही रहती हैं और कभी अपलोड नहीं होतीं। सामग्री-प्रकार पर कोई प्रतिबंध नहीं है, और `MAX_LOCAL_ONLY_FILE_UPLOAD_BYTES` (डिफ़ॉल्ट `104857600`, 100 MB) प्रत्येक अपलोड का अधिकतम आकार सीमित करता है। फ़ाइलें केवल तब जोड़ी जा सकती हैं जब इवेंट अभी भी ड्राफ्ट हो, इसलिए पाइपलाइन को इवेंट बनाना होगा `draft: true` , फ़ाइल संलग्न करनी होगी, फिर अंतिम रूप देना होगा।

दोनों का विस्तार से वर्णन [REST API संदर्भ](/deployment/hi/self-hosted/enterprise/deployment-manager/services/event-store/rest-api.md).

## क्लाउड बैकअप

जब डिवाइस पर Vision Events बैकअप सक्षम होता है, तो अंतिम रूप दिए गए इवेंट्स Roboflow पर अपलोड होते हैं। दो मोड उपलब्ध हैं:

* Records and Files, संबद्ध छवि फ़ाइलों, प्रति-छवि मेटाडेटा और वीडियो क्लिप्स के साथ इवेंट मेटाडेटा अपलोड करता है।
* Records Only केवल इवेंट मेटाडेटा अपलोड करता है और छवियों तथा वीडियो को डिवाइस पर छोड़ देता है, जिससे बैंडविड्थ कम लगती है।

केवल-स्थानीय फ़ाइलें किसी भी मोड में कभी अपलोड नहीं होतीं।

Records and Files मोड में, MP4 और MOV क्लिप्स अपलोड होती हैं, प्रति इवेंट अधिकतम चार तक, और Vision Events डैशबोर्ड में चलती हैं। अन्य फ़ॉर्मैट (जैसे MKV, AVI), चौथी के बाद की क्लिप्स, और 3 GB (क्लाउड सीमा) से बड़ी क्लिप्स डिवाइस पर रहती हैं। डिवाइस सीमा ("अधिकतम वीडियो अपलोड आकार (MB)") अलग है और डिफ़ॉल्ट रूप से 1 GB होती है, इसलिए इसे 3 GB से ऊपर केवल उन क्लिप्स के लिए बढ़ाएँ जिन्हें आप डिवाइस पर रखना चाहते हैं।

एक विफल क्लिप अपलोड पूरे इवेंट को `UPLOAD_RETRY_DELAY_SECONDS` (डिफ़ॉल्ट `3600`, 1 घंटा) के लिए रोक देती है, इससे पहले कि अगला प्रयास हो। `VIDEO_UPLOAD_MAX_ATTEMPTS` विफलताओं के बाद (डिफ़ॉल्ट `3`), क्लिप छोड़ दी जाती है और इवेंट उसके बिना अपलोड होता है, इसलिए वह इवेंट Roboflow तक लगभग 3 घंटे देरी से पहुँच सकता है।

देखें [इवेंट्स भेजें](/deployment/hi/monitoring-and-analytics/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>रिकॉर्ड तब तक बार-बार प्रयास करते हैं जब तक वे सफल न हों। डेटा के लिए सबसे सुरक्षित, लेकिन अटके हुए रिकॉर्ड्स से भरा डिवाइस नए writes को छोड़ने के बजाय HTTP 529 के साथ अस्वीकार करना शुरू कर देता है।</td></tr><tr><td>अधिकतम प्रयासों के बाद छोड़ें</td><td><code>ABANDON_AFTER_MAX_ATTEMPTS</code></td><td>के बाद <code>UPLOAD_MAX_ATTEMPTS</code> सामग्री-त्रुटि प्रयास (डिफ़ॉल्ट <code>10</code>) के बाद एक रिकॉर्ड को छोड़ा हुआ चिह्नित किया जाता है और वह storage cleanup के लिए पसंदीदा उम्मीदवार बन जाता है। यदि लगातार विफल होने वाले रिकॉर्ड खो देना नए writes को ब्लॉक करने से बेहतर हो, तो इसका उपयोग करें।</td></tr></tbody></table>

सर्वर से केवल content-style 4xx प्रतिक्रियाएँ (जैसे 400, 413, 422) प्रयास काउंटर बढ़ाती हैं। सभी 5xx प्रतिक्रियाएँ, समय-सीमा समाप्त होना, नेटवर्क त्रुटियाँ, और 401, 403, 404, 408, तथा 429 को अस्थायी माना जाता है और नीति की परवाह किए बिना पुनः प्रयास किया जाता है।

`MIN_UPLOAD_IMAGE_BYTES` (डिफ़ॉल्ट `1`) अपलोड से पहले दिए गए आकार से छोटी छवियों को छोड़ देता है। दूषित लेकिन खाली न होने वाली छवियाँ वर्तमान में सर्वर से 5xx के रूप में वापस आती हैं और इसलिए किसी भी नीति के तहत हमेशा पुनः प्रयास होती रहती हैं। इस मान को सामान्य भ्रष्टाचार आकारों से ऊपर बढ़ाना अस्थायी समाधान है।

## प्रमाणीकरण

API कुंजी प्रमाणीकरण वैकल्पिक है और डिफ़ॉल्ट रूप से बंद है। इसे सेवा पर सेट करें ताकि यह चालू हो जाए, जिसके बाद `API_KEY`  हर endpoint को छोड़कर `/health` को `X-API-Key` हेडर की आवश्यकता होती है।

```yaml
environment:
  - 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` प्रमाणीकरण के बिना भी पहुंच योग्य रहता है, इसलिए मॉनिटरिंग सिस्टम और लोड बैलेंसर इसे पोल कर सकते हैं।
