Event Store
automatic retention, storage limits, और वैकल्पिक cloud backup के साथ edge device पर inference events संग्रहित करें।
Event Store एक एज कंटेनर सेवा है जो डिवाइस पर इन्फरेंस पाइपलाइनों द्वारा उत्पन्न इवेंट्स को रिकॉर्ड करती है। यह निरीक्षण परिणाम, गुणवत्ता जाँच, सुरक्षा अलर्ट, और अन्य Workflow आउटपुट्स को स्थानीय रूप से रखती है, उन्हें REST API के माध्यम से वापस उपलब्ध कराती है, और अपनी डिस्क उपयोगिता स्वयं प्रबंधित करती है ताकि डिवाइस कभी भर न जाए।
Event Store में लिखे गए इवेंट्स को Roboflow में भी इस रूप में बैकअप किया जा सकता है Vision Events दीर्घकालिक संग्रहण और विश्लेषण के लिए।
कनेक्शन विवरण
बदलें <device-ip> को Deployment Manager में डिवाइस पेज पर दिखाई गई IP address से।
REST API
http://<device-ip>:8001
इंटरैक्टिव Swagger दस्तावेज़
http://<device-ip>:8001/docs
पोर्ट 8001 दोनों को HTTP पर सर्व करता है। देखें Event Store REST API एंडपॉइंट संदर्भ के लिए।
API को कॉल किए बिना किसी डिवाइस की लाइव क्षमता और उपयोग इतिहास देखने के लिए, उपयोग करें Event Store स्थिति देखें.
संग्रहण सेटिंग्स
इन्हें डिवाइस के Configuration टैब पर Event Store कार्ड से कॉन्फ़िगर करें। प्रत्येक सेवा पर एक environment variable से मैप होता है।
"धारण दिन"
RETENTION_DAYS
1
इतने दिनों से पुराने इवेंट्स हटा दिए जाते हैं।
"अधिकतम रिकॉर्ड"
MAX_RECORDS
1000000
रखी जाने वाली इवेंट्स की अधिकतम संख्या। सीमा पार होने पर सबसे पुराने हटा दिए जाते हैं।
"अधिकतम रिकॉर्ड आकार"
MAX_RECORD_SIZE_BYTES
524288 (512 KB)
एकल इवेंट रिकॉर्ड का अधिकतम आकार। इससे बड़े इवेंट अस्वीकार कर दिए जाते हैं।
"अधिकतम संग्रहण"
MAX_STORAGE_BYTES
5368709120 (5 GB)
संग्रहीत फ़ाइलों के लिए कुल डिस्क सीमा। उपयोग इस सीमा के करीब आने पर Cleanup फ़ाइलों को छाँट देता है।
"सफाई अंतराल"
CLEANUP_INTERVAL_SECONDS
300
स्वचालित सफाई कितनी बार चलती है।
अतिरिक्त चर:
PORT
8001
API के लिए HTTP पोर्ट।
DATA_DIR
/data
डिवाइस पर डेटा संग्रहण निर्देशिका।
CONSISTENCY_CHECK_INTERVAL
12
हर N सफाइयों पर एक consistency check चलाएँ (डिफ़ॉल्ट cleanup interval पर लगभग प्रति घंटे)।
स्वचालित सफाई
Cleanup एक समर्पित background thread पर चलता है, इसलिए यह कभी API अनुरोधों को अवरुद्ध नहीं करता। प्रत्येक निर्धारित पास क्रम में तीन चरण चलाता है:
धारण। इससे पुराने रिकॉर्ड हटाएँ
RETENTION_DAYS.रिकॉर्ड सीमा। यदि रिकॉर्डों की संख्या इससे अधिक हो जाए
MAX_RECORDS, तो सीमा से अधिक रिकॉर्ड हटाएँ, पहले पहले से अपलोड किए गए रिकॉर्ड और फिर सबसे पुराने।संग्रहण सीमा। जैसे-जैसे संग्रहीत फ़ाइलें करीब आती हैं
MAX_STORAGE_BYTES, तो इमेज फ़ाइलें हटाएँ, पहले पहले से अपलोड की गई फ़ाइलें और फिर सबसे पुरानी। मूल रिकॉर्ड सुरक्षित रहता है और उसकाcurrent_file_countघटाया जाता है।
हर CONSISTENCY_CHECK_INTERVAL सफाइयों पर सेवा डेटाबेस का फ़ाइल सिस्टम के साथ मिलान भी करती है। यह डिस्क पर मौजूद उन orphaned फ़ाइलों को हटाती है जिनका कोई मेल खाता डेटाबेस रिकॉर्ड नहीं है, इसके लिए 10 मिनट की grace period का उपयोग करती है ताकि चल रहे write प्रभावित न हों, और उन dangling डेटाबेस रिकॉर्डों को हटाती है जिनकी फ़ाइल पहले ही गायब हो चुकी है।
आप इसके साथ तुरंत एक पास भी ट्रिगर कर सकते हैं POST /admin/cleanup. देखें प्रशासन.
छवि क्षणभंगुरता
API द्वारा लौटाए गए इमेज ID स्वभाव से ही अल्पकालिक होते हैं। जो ID एक मिनट पहले resolve हुआ था, वह cleanup pass के बाद 404 दे सकता है, और यह संग्रहण-सीमित edge हार्डवेयर पर जानबूझकर ऐसा ही है।
संभालें
404छवियाँ प्राप्त करते समय प्रतिक्रियाएँ।इमेज ID को एकल सत्र से आगे कैश न करें।
तुलना करें
current_file_countके विरुद्धoriginal_file_countकिसी इवेंट पर यह जानने के लिए कि उसकी फ़ाइलें साफ़ की गई थीं या नहीं।
ड्राफ्ट इवेंट्स और वीडियो
एक पाइपलाइन इवेंट को तुरंत सहेज सकती है और एन्कोडिंग पूरी होने के कुछ सेकंड बाद वीडियो संलग्न कर सकती है। इवेंट को इस साथ बनाएँ draft: true, वीडियो तैयार होने पर अपलोड करें, फिर इवेंट को अंतिम रूप दें। बिना बनाए गए इवेंट ड्राफ्ट निर्माण के समय ही अंतिम रूप दे दिए जाते हैं, इसलिए मौजूदा पाइपलाइनों पर कोई असर नहीं पड़ता।
जब तक किसी इवेंट को अंतिम रूप नहीं दिया जाता, उसे cloud upload में छोड़ दिया जाता है। उसे cleanup से भी सुरक्षा मिलती है, लेकिन केवल तब जब सेवा पर cloud upload सक्षम हो; cloud upload बंद होने पर, ड्राफ्ट किसी भी अन्य रिकॉर्ड की तरह हटाया जा सकता है।
"इसके बाद ड्राफ्ट स्वतः अंतिम करें"
DRAFT_AUTO_FINALIZE_SECONDS
3600
जिस ड्राफ्ट का वीडियो कभी नहीं आता, उसे इतने सेकंड बाद जबरन अंतिम रूप दिया जाता है ताकि उसका बैकअप लिया जा सके और उसे साफ़ किया जा सके।
"अधिकतम वीडियो अपलोड आकार"
MAX_VIDEO_UPLOAD_BYTES
1073741824 (1 GB)
किसी इवेंट से संलग्न की जा सकने वाली सबसे बड़ी एकल वीडियो फ़ाइल।
सेटिंग DRAFT_AUTO_FINALIZE_SECONDS से 0 स्वीप को निष्क्रिय करता है। जो producer कभी finalize नहीं बुलाता, उसके ड्राफ्ट फिर जमा होते रहते हैं और cloud backup चालू होने पर स्टोर को भर सकते हैं तथा store रीसेट होने तक HTTP 529 के साथ नए writes को रोक सकते हैं।
प्रति-छवि मेटाडेटा और केवल-स्थानीय फ़ाइलें
पाइपलाइन किसी इवेंट से अतिरिक्त डेटा संलग्न कर सकती हैं जो डिवाइस पर ही रहता है और कभी cloud पर अपलोड नहीं किया जाता।
प्रति-छवि मेटाडेटा key/value डेटा का एक छोटा single-level object है जो किसी व्यक्तिगत छवि से जुड़ा होता है, जैसे verdict, serial number, या angle label। यह रिकॉर्ड के साथ संग्रहीत होता है और API द्वारा लौटाया जाता है, लेकिन इसे query नहीं किया जा सकता और यह बैकअप से बाहर रखा जाता है। METADATA_MAX_VALUE_LENGTH (डिफ़ॉल्ट 1000) किसी string value की लंबाई सीमित करता है।
केवल-स्थानीय फ़ाइलें वे मनमानी फ़ाइलें हैं जो किसी इवेंट से संलग्न होती हैं, जैसे inspection blobs, thumbnails, या JSON। कोई content-type प्रतिबंध नहीं है, और MAX_LOCAL_ONLY_FILE_UPLOAD_BYTES (डिफ़ॉल्ट 104857600, 100 MB) प्रत्येक अपलोड की सीमा निर्धारित करता है। फ़ाइलें केवल तब संलग्न की जा सकती हैं जब इवेंट अभी भी ड्राफ्ट हो, इसलिए पाइपलाइन को इवेंट इस साथ बनाना चाहिए draft: true, फ़ाइल संलग्न करें, फिर अंतिम रूप दें।
दोनों का विस्तृत वर्णन में किया गया है REST API संदर्भ.
क्लाउड बैकअप
जब डिवाइस पर Vision Events बैकअप सक्षम होता है, तब अंतिम रूप दिए गए इवेंट Roboflow पर अपलोड किए जाते हैं। दो मोड उपलब्ध हैं:
Records and Files इवेंट मेटाडेटा को संबद्ध छवि फ़ाइलों के साथ अपलोड करता है।
Records Only इवेंट मेटाडेटा अपलोड करता है और छवियों को डिवाइस पर ही छोड़ देता है, जिससे कम bandwidth उपयोग होती है।
प्रति-छवि मेटाडेटा और केवल-स्थानीय फ़ाइलें किसी भी मोड में कभी अपलोड नहीं की जातीं।
देखें इवेंट भेजें बैकअप सक्षम करने और Roboflow में परिणामों को query करने के लिए।
अपलोड विश्वसनीयता
विफल अपलोड पुनः प्रयास किए जाते हैं। "अपलोड परित्याग नीति" नियंत्रित करती है कि उस रिकॉर्ड का क्या होगा जिसे सर्वर बार-बार अस्वीकार करता रहता है।
कभी न छोड़ें
NEVER_ABANDON (डिफ़ॉल्ट)
रिकॉर्ड तब तक अनंत बार पुनः प्रयास करते रहते हैं जब तक वे सफल न हो जाएँ। डेटा के लिए सबसे सुरक्षित, लेकिन अटके हुए रिकॉर्डों से भरता हुआ डिवाइस नए writes को HTTP 529 के साथ अस्वीकार करना शुरू कर देता है, बजाय अपलोड न किए गए रिकॉर्डों को हटाने के।
अधिकतम प्रयासों के बाद छोड़ दें
ABANDON_AFTER_MAX_ATTEMPTS
के बाद UPLOAD_MAX_ATTEMPTS content-error प्रयास (डिफ़ॉल्ट 10) किसी रिकॉर्ड को परित्यक्त चिह्नित किया जाता है और वह storage cleanup के लिए प्राथमिक उम्मीदवार बन जाता है। इसका उपयोग करें यदि लगातार विफल रिकॉर्डों को खो देना नए writes को रोकने से बेहतर है।
सर्वर से केवल content-style 4xx प्रतिक्रियाएँ (उदा: 400, 413, 422) ही प्रयास काउंटर बढ़ाती हैं। सभी 5xx प्रतिक्रियाएँ, timeouts, network errors, और 401, 403, 404, 408, तथा 429 को अस्थायी माना जाता है और नीति की परवाह किए बिना पुनः प्रयास किया जाता है।
MIN_UPLOAD_IMAGE_BYTES (डिफ़ॉल्ट 1) अपलोड से पहले दिए गए आकार से छोटी छवियों को छोड़ देता है। दूषित लेकिन खाली न होने वाली छवियाँ वर्तमान में सर्वर से 5xx के रूप में वापस आती हैं और इसलिए किसी भी नीति के तहत अनंत बार पुनः प्रयास करती रहती हैं। इस मान को सामान्य corruption sizes से ऊपर बढ़ाना workaround है।
प्रमाणीकरण
API key प्रमाणीकरण वैकल्पिक है और डिफ़ॉल्ट रूप से बंद है। इसे चालू करने के लिए सेवा पर सेट करें API_KEY जिसके बाद हर endpoint, सिवाय /health को आवश्यक होगा X-API-Key हेडर।
/health प्रमाणीकरण के बिना भी पहुँच योग्य रहता है ताकि monitoring systems और load balancers इसे poll कर सकें।
अंतिम अपडेट
क्या यह उपयोगी था?