System Design Interview: एक सेंट्रलाइज़्ड लॉगिंग सिस्टम डिज़ाइन करें

समस्या और दायरा (Problem and Scope)

एक ऐसा सेंट्रलाइज़्ड लॉगिंग सिस्टम डिज़ाइन करें जो कई इंजीनियरिंग टीमों द्वारा साझा किया जाता हो। एक लाख सर्विस इंस्टेंस, कंटेनर और बैच जॉब स्थिर अवस्था में औसतन प्रति इवेंट 600 बाइट्स के रॉ डेटा के साथ प्रति सेकंड 10 लाख इवेंट्स उत्पन्न करते हैं। किसी बड़े इंसिडेंट के दौरान 15 मिनट के लिए प्रति सेकंड 30 लाख इवेंट्स का लोड बना रह सकता है क्योंकि फेल्ड रिक्वेस्ट्स, रीप्रयास (retries) और स्टैक ट्रेसेस सभी एक साथ बढ़ जाते हैं। इवेंट बनने से लेकर सर्च में दिखने तक का p99 लक्ष्य 30 सेकंड है। टेनेंट, समय, सर्विस, एनवायरनमेंट और सेवेरिटी फ़िल्टर्स के साथ पिछले 15 मिनट के सामान्य प्रश्नों (queries) को p95 पर 2 सेकंड के भीतर पूरा होना चाहिए।

उपयोगकर्ताओं को समय, सर्विस, होस्ट, सेवेरिटी और traceId के अनुसार फ़िल्टर के साथ-साथ बाउंडेड फ़ुल-टेक्स्ट सर्च, डाउनलोड और अलर्ट की आवश्यकता होती है। लॉग क्लासों की अलग-अलग रिटेंशन और रिलायबिलिटी आवश्यकताएं होती हैं। डीबग लॉग्स का रिटेंशन कम हो सकता है और आपात स्थिति के दौरान उनका सैंपल लिया जा सकता है। ऑपरेशनल एरर्स को ड्यूरेबल रिटेंशन की आवश्यकता होती है। सुरक्षा ऑडिट लॉग्स सामान्य डिग्रेडेशन पॉलिसी का उपयोग नहीं कर सकते। सिस्टम को टेनेंट कोटा, फ़ील्ड रिडैक्शन, एक्सेस ऑडिटिंग, लाइफ़साइकिल मैनेजमेंट और ऐतिहासिक डेटा की पुनर्प्राप्ति (historical restoration) की भी आवश्यकता होती है।

यह स्केल, लेटेंसी, रिटेंशन और रिलायबिलिटी लक्ष्य इंटरव्यू के इनपुट हैं, किसी लॉगिंग वेंडर की सार्वजनिक प्रतिबद्धताएं नहीं। इस दायरे में इंटरव्यू के दौरान पूरा सर्च इंजन लागू करना या मैसेज ब्रोकर को फिर से लिखना शामिल नहीं है। इसके लिए किसी कंपनी के आंतरिक आर्किटेक्चर की नकल करने की भी आवश्यकता नहीं है। सार्वजनिक 2026 सिस्टम-डिज़ाइन प्रश्न अभी भी उम्मीदवारों से बर्स्ट हैंडलिंग, सर्च, रिटेंशन और टेनेंट आइसोलेशन के साथ सेंट्रलाइज़्ड लॉगिंग डिज़ाइन करने के लिए कहते हैं। OpenTelemetry का स्टेबल लॉग डेटा मॉडल, इसका Collector ट्रबलशूटिंग गाइडेंस, और डेटा टियर्स व मैपिंग एक्सप्लोज़न पर Elastic का दस्तावेज़ीकरण महत्वपूर्ण इंजीनियरिंग सीमाओं के लिए प्राथमिक साक्ष्य प्रदान करते हैं।

इंटरव्यूअर क्या मूल्यांकन कर रहा है (What the Interviewer Is Evaluating)

पहला, क्या उम्मीदवार ड्यूरेबल एक्सेप्टेंस को तत्काल सर्च की सुविधा से अलग कर सकता है? गेटवे किसी इवेंट को रेप्लिकेटेड ड्यूरेबल स्ट्रीम में कमिट करने के बाद एक्नॉलेज (स्वीकार) कर सकता है। सर्च इंडेक्स में कई दसियों सेकंड की देरी हो सकती है। यदि सफलता के लिए सर्च क्लस्टर में राइट (write) करना आवश्यक है, तो इंडेक्स मेंटेनेंस और स्केलिंग सीधे तौर पर प्रत्येक प्रोड्यूसर पर बैकप्रेशर डालेगी।

दूसरा, क्या उम्मीदवार किसी इंसिडेंट के दौरान सहसंबद्ध विफलता (correlated failure) को पहचानता है? जिस समय लॉग सबसे अधिक मूल्यवान होते हैं, ठीक उसी समय एप्लिकेशन एरर्स, रीट्राय स्टॉर्म्स और सर्च-क्लस्टर का दबाव भी अक्सर एक साथ बढ़ जाता है। एक संपूर्ण उत्तर में लोकल डिस्क बफरिंग, एक सेंट्रल ड्यूरेबल कतार, बैकप्रेशर, सीमित कैपेसिटी, प्राथमिकता-आधारित शेडिंग (shedding), और मापने योग्य ड्रॉप काउंट शामिल होते हैं। केवल “Kafka और Elasticsearch जोड़ें” कहने से विफलता का मार्ग बंद नहीं होता।

तीसरा, क्या इंडेक्सिंग प्लान लागत और कार्डिनैलिटी को समझता है? प्रत्येक मनमाने JSON एट्रिब्यूट को डायनेमिक रूप से इंडेक्स करने से हाई-कार्डिनैलिटी फ़ील्ड्स मैपिंग, डिक्शनरी और शार्ड ओवरहेड बना देती हैं। एक सटीक डिज़ाइन स्टेबल, बार-बार पूछे जाने वाले और सही टाइप वाले फ़ील्ड्स को इंडेक्स करता है। अन्य एट्रिब्यूट्स को डिफ़ॉल्ट रूप से इंडेक्स किए बिना भी स्टोर किया जा सकता है।

चौथा, क्या टेनेंट आइसोलेशन इनजेशन और क्वेरी दोनों को कवर करता है? टेनेंट की पहचान प्रमाणित क्रेडेंशियल्स से आनी चाहिए, लॉग बॉडी के अंदर दिए गए tenantId से नहीं। एक हाई-वॉल्यूम टेनेंट, व्यापक रेगुलर एक्सप्रेशन, या फ़ील्ड एक्सप्लोज़न को शेयर्ड कतारों, इंडेक्सिंग थ्रेड्स, कैश या क्वेरी कन्करेंसी को समाप्त नहीं करना चाहिए।

अंत में, क्या कैपेसिटी, डिलीवरी सिमेंटिक्स, सुरक्षा और वैलिडेशन मिलकर एक सुसंगत सिस्टम बनाते हैं? उम्मीदवार को रॉ थ्रूपुट और बर्स्ट बैकलॉग की गणना करनी चाहिए, यह स्वीकार करना चाहिए कि एट-लीस्ट-वन्स (at-least-once) डिलीवरी से डुप्लीकेट्स बनते हैं, यह स्पष्ट करना चाहिए कि ऑडिट और डीबग लॉग्स को अलग-अलग पॉलिसियों की आवश्यकता क्यों है, और यह साबित करने के लिए एंड-टू-एंड कैनरीज़ का उपयोग करना चाहिए कि डेटा लॉस कभी भी अनदेखा (silent) न रहे।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न (Clarifying Questions Before Answering)

• किन लॉग्स को खोया नहीं जाना चाहिए? ऑडिट और सुरक्षा इवेंट्स के लिए ड्यूरेबल रिटेंशन की आवश्यकता होती है। एक स्पष्ट डिग्रेडेशन पॉलिसी के तहत डीबग लॉग्स का सैंपल लिया जा सकता है या उन्हें ड्रॉप किया जा सकता है।
• सफलता की सीमा (success boundary) कहाँ है? सेंट्रल गेटवे सर्च-इंडेक्स रिफ्रेश की प्रतीक्षा किए बिना, अवेलेबिलिटी ज़ोन में रेप्लिकेटेड एक ड्यूरेबल स्ट्रीम में इवेंट कमिट करने के बाद एक्नॉलेज करता है।
• क्या लॉगिंग प्रोड्यूसर को ब्लॉक कर सकती है? सामान्य एप्लिकेशन लॉग्स को बिजनेस रिक्वेस्ट्स को सिंक्रोनस रूप से ब्लॉक नहीं करना चाहिए। एक नोड एजेंट एसिंक्रोनस बैच और सीमित लोकल डिस्क का उपयोग करता है।
• प्राथमिक क्वेरी पैटर्न क्या हैं? टेनेंट और समय सीमा के साथ स्ट्रक्चर्ड फ़िल्टर, सटीक traceId लुकअप, और एक निश्चित विंडो पर फ़ुल-टेक्स्ट सर्च।
• क्या ग्लोबल ऑर्डरिंग आवश्यक है? नहीं। एक सोर्स इंस्टेंस के भीतर अनुमानित क्रम बनाए रखें और विभिन्न सोर्सेज में इवेंट्स को क्रमबद्ध करने में मदद के लिए इवेंट व ऑब्ज़र्व्ड टाइमस्टैम्प का उपयोग करें।
• रिटेंशन से जुड़ी क्या धारणाएं हैं? डीबग लॉग्स हॉट इंडेक्स में 24 घंटे और रॉ आर्काइव्स में 7 दिन रहते हैं। ऑपरेशनल लॉग्स हॉट में 7 दिन और आर्काइव में 90 दिन रहते हैं। ऑडिट लॉग्स 30 दिन सर्च योग्य और 365 दिन इम्यूटैबल आर्काइव्स में रहते हैं।
• क्या हमें विभिन्न क्षेत्रों (regions) में एक्टिव राइट्स की आवश्यकता है? प्राथमिक डिज़ाइन एक रीजनल पाइपलाइन में डेटा एकत्र करता है। एक यूनिफ़ाइड कंट्रोल प्लेन और डिजास्टर-रिकवरी क्वेरीज़ आर्काइव्स को पढ़ सकती हैं।
• क्या हम हर फ़ील्ड को इंडेक्स करते हैं? नहीं। स्टेबल टॉप-लेवल फ़ील्ड्स और अनुमति प्राप्त (allowlisted) एट्रिब्यूट्स को इंडेक्स किया जा सकता है। मनमाने हाई-कार्डिनैलिटी एट्रिब्यूट्स केवल डिफ़ॉल्ट रूप से स्टोर किए जाते हैं।
• संवेदनशील मानों (sensitive values) को कैसे संभाला जाता है? SDK और नोड एजेंट पहले उन्हें रोकते हैं या रिडैक्ट (संपादित) करते हैं, और सेंट्रल प्रोसेसर्स फिर से जांच करते हैं। सीक्रेट्स और टोकन्स लॉग्स में प्रवेश नहीं करने चाहिए।
• एक क्वेरी कितनी व्यापक हो सकती है? इसके लिए एक समय सीमा, कर्सर पेजिनेशन, स्कैन बजट, कन्करेंसी सीमाएं और कैंसलेशन की आवश्यकता होती है। बड़े ऐतिहासिक एक्सपोर्ट एसिंक्रोनस जॉब्स का उपयोग करते हैं।

30-सेकंड का उत्तर ढांचा (30-Second Answer Framework)

“एप्लिकेशंस stdout या एसिंक्रोनस SDK में राइट करती हैं। एक नोड एजेंट बैचिंग करता है, रिडैक्ट करता है, और सीमित डिस्क स्पूल का उपयोग करता है। एक रीजनल गेटवे वर्कलोड को प्रमाणित करता है, टेनेंट को बाइंड करता है, कोटा लागू करता है, और अवेलेबिलिटी ज़ोन में रेप्लिकेटेड ड्यूरेबल स्ट्रीम में राइट करने से पहले प्रारूप को वैलिडेट करता है। वह कमिट ही एक्नॉलेजमेंट की सीमा है। प्रोसेसर्स इवेंट्स को नॉर्मलाइज़ करते हैं, ऑब्जेक्ट स्टोरेज में रॉ रिकॉर्ड्स लिखते हैं, और स्वीकृत फ़ील्ड्स व चुनिंदा टेक्स्ट को हॉट सर्च इंडेक्स में लिखते हैं। क्वेरी सर्विस को टेनेंट और समय की शर्तों की आवश्यकता होती है और यह हॉट, वार्म और आर्काइव स्टोरेज में विंडो को रूट करती है। स्थिर रॉ ट्रैफ़िक लगभग 600 MB/s या 51.84 TB/दिन है। 15 मिनट का 3x बर्स्ट स्थिर प्रोसेसिंग के ऊपर लगभग 1.08 TB का बैकलॉग बनाता है। डिलीवरी eventId डिडुप्लीकेशन के साथ एट-लीस्ट-वन्स है। ओवरलोड के दौरान, पहले ऑडिट और एरर लॉग्स को सुरक्षित रखें, पहले डीबग लॉग्स का सैंपल लें, और प्रत्येक ड्रॉप को एक अलर्ट योग्य मीट्रिक के रूप में दिखाएं।”

चरण-दर-चरण विस्तृत विश्लेषण (Step-by-Step Deep Dive)

छह इनवेरिएंट्स के साथ शुरुआत करें:

1. एक सामान्य बिजनेस रिक्वेस्ट को रिमोट लॉगिंग प्लेटफ़ॉर्म पर सिंक्रोनस रूप से निर्भर नहीं होना चाहिए।
2. सेंट्रल सिस्टम किसी इवेंट को रेप्लिकेटेड ड्यूरेबल बफरिंग तक पहुँचने के बाद ही स्वीकार (acknowledge) करता है।
3. टेनेंट की पहचान प्रमाणीकरण से आती है, और इनजेशन, स्टोरेज, सर्च और एक्सपोर्ट टेनेंट की सीमाओं को पार नहीं कर सकते।
4. ऑडिट लॉग्स डीबग लॉग्स की सैंपलिंग और शेडिंग पॉलिसी का उपयोग नहीं करते हैं।
5. मनमाने यूजर एट्रिब्यूट्स डिफ़ॉल्ट रूप से डायनेमिक रूप से इंडेक्स नहीं होते हैं, इसलिए हाई-कार्डिनैलिटी फ़ील्ड्स बिना किसी सीमा के स्कीमा को नहीं बढ़ा सकते।
6. ड्रॉप्स, डिले, पार्स विफलताएं और रिडैक्शन विफलताएं मापने योग्य हैं और कभी भी मूक (silent) नहीं होती हैं।

चरण 1: कलेक्शन पाथ और एक्नॉलेजमेंट सीमा को परिभाषित करें।

Application stdout / asynchronous SDK
  -> node agent or sidecar: batch, compress, redact, local disk spool
  -> regional ingestion gateway: authenticate, bind tenant, quota, mandatory redaction, format and size limits
  -> durable stream replicated across availability zones
  -> normalization and routing processors
       -> raw object-storage archive
       -> hot search index
       -> alerts and streaming subscriptions
  -> query coordinator -> hot / warm / archive readers

एप्लिकेशंस आम तौर पर stdout में लिखती हैं ताकि नोड एजेंट बिजनेस प्रोसेस से अलग (decoupled) रहे। स्पष्ट रूप से स्ट्रक्चर्ड इवेंट्स के लिए एक एसिंक्रोनस SDK उचित है, लेकिन यह अभी भी इन-मेमोरी कतार या लोकल एजेंट में लिखता है। एजेंट बाइट्स और समय के अनुसार बैच बनाता है, व्यक्तिगत इवेंट आकार को सीमित करता है, अपनी स्थिति को बनाए रखता है, और नेटवर्क विफलता के दौरान एक सीमित डिस्क स्पूल का उपयोग करता है। जब डिस्क भर जाती है, तो यह हमेशा के लिए ब्लॉक होने या असीमित डिस्क की खपत करने के बजाय लॉग क्लास के अनुसार एक पॉलिसी का पालन करता है।

रीजनल गेटवे mTLS पहचान, वर्कलोड पहचान, या शॉर्ट-लिव्ड क्रेडेंशियल्स से टेनेंट, सर्विस और एनवायरनमेंट प्राप्त करता है, जो बॉडी में स्पूफ़ किए गए फ़ील्ड्स को ओवरराइड करता है। डेटा के सेंट्रल ड्यूरेबल बफ़र में प्रवेश करने से पहले यह रेट लिमिट लागू करता है, कम्प्रेशन को डिकोड करता है, बुनियादी स्कीमा जांच करता है, अधिकतम इवेंट आकार लागू करता है, और अनिवार्य सीक्रेट व टोकन रिडैक्शन लागू करता है। यह किसी इवेंट को अवेलेबिलिटी ज़ोन में ड्यूरेबल स्ट्रीम में रेप्लिकेट होने के बाद ही एक्नॉलेज करता है। सर्च, आर्काइव्स और अलर्ट अलग-अलग कंज्यूमर्स हैं, इसलिए एक फेल्ड कंज्यूमर हर प्रोड्यूसर की सीधी निर्भरता नहीं बनता है।

चरण 2: नियंत्रित एक्सटेंशन पॉइंट्स के साथ एक सामान्य डेटा मॉडल का उपयोग करें।

LogEvent(
  eventId, timestamp, observedTimestamp,
  tenantId, service, environment, instance,
  severityNumber, severityText, body,
  traceId, spanId, schemaVersion,
  attributes, sensitivityClass
)

timestamp वह समय है जब इवेंट हुआ था, जबकि observedTimestamp वह समय है जब कलेक्शन सिस्टम ने इसे पहली बार देखा था। यदि सोर्स क्लॉक ड्रिफ़्ट होती हैं, तब भी बाद वाला इनजेशन ऑर्डर और डिले को दिखाता है। traceId और spanId लॉग्स को डिस्ट्रीब्यूटेड ट्रेसेस से जोड़ते हैं। severityNumber नॉर्मलाइज़्ड तुलना का समर्थन करता है जबकि severityText प्रोड्यूसर के शब्दों को सुरक्षित रखता है। schemaVersion प्रोसेसर्स को पार्सिंग नियमों को सुरक्षित रूप से अपग्रेड करने की अनुमति देता है।

स्टेबल टॉप-लेवल फ़ील्ड्स में स्पष्ट प्रकार और इंडेक्स होते हैं। attributes अतिरिक्त स्ट्रक्चर्ड डेटा को बनाए रखता है, लेकिन केवल रजिस्टर्ड अनुमत (allowlist) फ़ील्ड ही इंडेक्स मैपिंग में प्रवेश कर सकते हैं। अज्ञात एट्रिब्यूट्स एक फ़्लैट किए गए ऑब्जेक्ट, की-वैल्यू कॉलम या रॉ बॉडी का उपयोग कर सकते हैं। यदि वही फ़ील्ड किसी संख्या से ऑब्जेक्ट में बदल जाती है, तो प्रोसेसर इसे पार्स विफलता के रूप में क्वारंटाइन करता है या एक वर्ज़न वाली फ़ील्ड लिखता है। एक खराब डिप्लॉयमेंट को पूरे शेयर्ड इंडेक्स को नुकसान नहीं पहुँचाना चाहिए।

एजेंट सोर्स इंस्टेंस, बूट एपॉक और लोकल सीक्वेंस से eventId जनरेट कर सकता है। डिलीवरी एट-लीस्ट-वन्स है, इसलिए एक्नॉलेजमेंट न मिलने पर एजेंट पुनः प्रयास करता है। कंज्यूमर्स और इंडेक्स राइट्स idempotent रूप से eventId का उपयोग करते हैं। डिडुप्लीकेशन विंडो सीमित होती हैं, और आर्काइव्स में डुप्लीकेट्स रह सकते हैं। प्रश्नों और एग्रीगेट्स को महंगी, अस्थिर एंड-टू-एंड एक्ज़ैक्टली-वन्स डिलीवरी का दावा करने के बजाय इस सिमेंटिक को समझना चाहिए।

चरण 3: पार्टीशनिंग और टेनेंट आइसोलेशन की योजना बनाएं।

ड्यूरेबल स्ट्रीम वर्चुअल पार्टीशन्स के माध्यम से स्केल करती है। एक राउटिंग कुंजी (tenantId, sourceInstance) को हैश कर सकती है, जो एक सोर्स के लिए अनुमानित क्रम को बनाए रखते हुए एक टेनेंट को कई पार्टीशन्स में फैलाती है। केवल tenantId द्वारा पार्टीशन करने से एक बड़ा टेनेंट हॉटस्पॉट बन जाता है। विशुद्ध रूप से रैंडम पार्टीशनिंग से सोर्स-लोकल क्रम खो जाता है। बड़े टेनेंट्स डेडिकेटेड पार्टीशन पूल प्राप्त कर सकते हैं जबकि छोटे टेनेंट्स एक पूल साझा करते हैं, और कंट्रोल प्लेन इवेंट फ़ॉर्मेट को बदले बिना असाइनमेंट को पुनर्संतुलित कर सकता है।

प्रत्येक टेनेंट के पास इनजेस्ट बाइट्स, इवेंट रेट, बर्स्ट टोकन, लोकल व सेंट्रल बैकलॉग, इंडेक्स की गई फ़ील्ड संख्या, हॉट स्टोरेज, क्वेरी कन्करेंसी, स्कैन किए गए बाइट्स और एक्सपोर्ट जॉब्स के लिए कोटा होता है। रिजेक्शन और डिग्रेडेशन प्रति टेनेंट रिकॉर्ड किए जाते हैं। सिस्टम ओवरलोड के दौरान, प्राथमिकता क्रम यह हो सकता है:

1. ऑडिट और सुरक्षा इवेंट्स को सुरक्षित रखें।
2. एरर्स और महत्वपूर्ण ऑपरेशनल इवेंट्स को सुरक्षित रखें।
3. घोषित पॉलिसी के अनुसार दोहराए जाने वाले चेतावनियों, सूचनात्मक लॉग्स और डीबग लॉग्स का सैंपल लें।
4. नई कम प्राथमिकता वाली व्यापक क्वेरीज़ और एक्सपोर्ट्स को अस्वीकार करें।

एक शेयर्ड हॉट इंडेक्स छोटे टेनेंट्स के लिए काम करता है, लेकिन प्रत्येक डॉक्यूमेंट, कैश कुंजी और क्वेरी प्लान में एक विश्वसनीय tenantId शामिल होना चाहिए। बड़े या अत्यधिक विनियमित (regulated) टेनेंट्स आइसोलेटेड इंडेक्स और एन्क्रिप्शन सीमाओं का उपयोग कर सकते हैं। डिज़ाइन को न तो प्रत्येक छोटे टेनेंट के लिए कई खाली दैनिक शार्ड्स बनाने चाहिए और न ही प्रत्येक टेनेंट को एक असीमित शेयर्ड इंडेक्स में रखना चाहिए।

चरण 4: रॉ आर्काइव को सर्च इंडेक्स से अलग करें।

ऑब्जेक्ट स्टोरेज क्षेत्र, टेनेंट, दिनांक, घंटे और वैकल्पिक रूप से सर्विस द्वारा पार्टीशन की गई बड़ी कंप्रेस्ड कॉलमर फ़ाइलों में नॉर्मलाइज़्ड रॉ इवेंट्स रखता है। यह कम्प्लायंस एक्सपोर्ट्स, ऐतिहासिक स्कैन और क्षतिग्रस्त हॉट इंडेक्स के पुनर्निर्माण के लिए कम लागत वाला दीर्घकालिक स्रोत है। राइटर्स प्रति लॉग लाइन एक ऑब्जेक्ट बनाने के बजाय इवेंट्स को उपयुक्त आकार के ऑब्जेक्ट्स में एकत्रित करते हैं।

हॉट सर्च इंडेक्स केवल हालिया, सर्च करने योग्य डेटा स्टोर करता है। स्टेबल फ़ील्ड्स इनवर्टेड या कॉलम-ओरिएंटेड इंडेक्स का उपयोग करते हैं, जबकि बॉडी की फ़ुल-टेक्स्ट इंडेक्सिंग लॉग क्लास के अनुसार भिन्न हो सकती है। हाई-कार्डिनैलिटी रिक्वेस्ट आईडी, यूजर आईडी, या मनमाने टैग तब स्टोर्ड फ़ील्ड बने रहते हैं जब उनसे बार-बार क्वेरी नहीं की जाती है। traceId भी हाई कार्डिनैलिटी है, लेकिन इसका एक स्पष्ट सटीक-लुकअप उपयोग का मामला है, इसलिए यह सभी डायनेमिक फ़ील्ड्स के लिए मिसाल कायम करने के बजाय सीमित रिटेंशन के साथ एक डेडिकेटेड सटीक फ़ील्ड का उपयोग कर सकता है।

एक लाइफ़साइकिल कंट्रोलर डेटा को क्लास के अनुसार हॉट से वार्म, कोल्ड, फ्रोज़न या आर्काइव टियर्स में ले जाता है। राइट और कम-लेटेंसी सर्च के लिए हॉट स्टोरेज में अधिक कंप्यूट और रेप्लिका होते हैं। पुराने डेटा की लागत कम होती है और धीमी पहुंच स्वीकार्य होती है। रिटेंशन विलोपन (deletion) में इंडेक्स, आर्काइव्स, कैश, एक्सपोर्ट्स और लीगल होल्ड्स शामिल होने चाहिए। किसी एक सर्च इंडेक्स को हटाना एक पूर्ण विलोपन वर्कफ़्लो नहीं है।

चरण 5: एक नियंत्रित क्वेरी पाथ बनाएं।

क्वेरी API सत्र से tenantId प्राप्त करता है और डिफ़ॉल्ट रूप से startTime, endTime, और एक सर्विस या किसी अन्य सेलेक्टिव शर्त की आवश्यकता होती है। समन्वयक समय सीमा और लॉग क्लास की जांच करता है, फिर अनुरोध को हॉट इंडेक्स, वार्म स्टोरेज या एसिंक्रोनस आर्काइव स्कैन पर रूट करता है। उदाहरण इंटरफेस हैं:

POST /logs/search
  { startTime, endTime, services, severities, traceId, query, cursor, limit }
  -> { events[], nextCursor, partial, scannedBytes }

POST /logs/exports
  { startTime, endTime, filters }
  -> { jobId }

परिणाम डीप ऑफ़सेट के बजाय स्टेबल सॉर्ट कुंजी (timestamp, eventId) और कर्सर पेजिनेशन का उपयोग करते हैं। इंटरएक्टिव क्वेरीज़ में स्कैन किए गए बाइट्स, लौटाए गए रो, निष्पादन समय और कन्करेंसी की सीमाएं होती हैं। जब कोई सीमा पूरी हो जाती है, तो प्रतिक्रिया चुपचाप डेटा छोड़ने के बजाय एक स्पष्ट partial मार्कर लौटाती है। व्यापक रेगुलर एक्सप्रेशन्स, 90-दिवसीय फ़ुल-टेक्स्ट सर्च और बड़े एक्सपोर्ट एक एसिंक्रोनस कतार में प्रवेश करते हैं और उन्हें रद्द किया जा सकता है। सामान्य फ़िल्टर्स के लिए मेटाडेटा कैश किया जा सकता है, लेकिन पूर्ण आइसोलेशन के बिना टेनेंट्स के बीच क्वेरी परिणामों का पुनर्चक्रण (reuse) नहीं किया जा सकता।

2 सेकंड से कम का p95 लक्ष्य एक स्वस्थ क्लस्टर पर पिछले 15 मिनट की सेलेक्टिव फ़िल्टर्ड क्वेरीज़ पर लागू होता है। सभी रिटेन किए गए डेटा पर एक अनबाउंडेड फ़ुल-टेक्स्ट स्कैन उस SLO को साझा नहीं करता है। प्रत्येक क्वेरी के तेज़ होने का वादा करने से क्वेरी क्लासों को परिभाषित करना अधिक विश्वसनीय है।

चरण 6: कैपेसिटी की गणना करें।

स्थिर रॉ थ्रूपुट है:

1,000,000 events/s × 600 bytes = 600 MB/s
600 MB/s × 86,400 s = 51.84 TB/day

ट्रैफ़िक 15 मिनट के लिए प्रति सेकंड 10 लाख से बढ़कर 30 लाख इवेंट्स हो जाता है। यदि डाउनस्ट्रीम प्रोसेसिंग केवल स्थिर दर को बनाए रख सकती है, तो उसे इस अतिरिक्त बैकलॉग को संभालना होगा:

(3,000,000 - 1,000,000) × 600 bytes × 900 s = 1.08 TB

बर्स्ट उन 15 मिनटों के दौरान कुल 1.62 TB का उत्पादन करता है, लेकिन 0.54 TB वह बेसलाइन है जिसे स्थिर प्रोसेसिंग उसी समय संभालती है। वास्तविक बफ़रिंग के लिए रेप्लिकेशन, बैच ओवरहेड, रिकवरी कैपेसिटी और सुरक्षा हेडरूम की भी आवश्यकता होती है, इसलिए 1.08 TB हार्डवेयर-खरीद का आंकड़ा नहीं है।

यदि केवल 20% लॉग फ़ुल-टेक्स्ट या स्ट्रक्चर्ड हॉट इंडेक्स में प्रवेश करते हैं और 7 दिनों तक वहां रहते हैं, तो इंडेक्स ओवरहेड से पहले रॉ इनपुट अभी भी है:

51.84 TB/day × 20% × 7 = 72.576 TB

वास्तविक इंडेक्स का आकार फ़ील्ड्स, कम्प्रेशन, शार्ड्स और रेप्लिका पर निर्भर करता है और इसे लोड टेस्टिंग द्वारा मापा जाना चाहिए। 90 दिनों का रॉ आर्काइव 51.84 TB × 90 = 4.6656 PB है, या कम्प्रेशन से पहले लगभग 4.67 PB है। यह पैमाना केवल सर्च क्लस्टर को बड़ा करने की तुलना में टियरिंग, क्लास-आधारित रिटेंशन, कम्प्रेशन और कम मूल्य वाले लॉग्स को हटाने को अधिक महत्वपूर्ण बनाता है।

प्रति पार्टीशन लगातार बने रहने वाले बाइट्स, प्रति पार्टीशन इवेंट्स और आवश्यक रीप्ले स्पीड से पार्टीशन काउंट प्राप्त करें। कैपेसिटी परीक्षणों में एक खोया हुआ अवेलेबिलिटी ज़ोन, कंज्यूमर कैच-अप और एक 3x बर्स्ट शामिल होना चाहिए, जबकि यह सुनिश्चित करना चाहिए कि सबसे पुराने मैसेज की उम्र अंततः ठीक हो जाए। केवल इवेंट्स की गिनती करना अपर्याप्त है क्योंकि स्टैक ट्रेसेस औसत आकार को तेजी से बदल सकते हैं।

चरण 7: बैकप्रेशर, लॉग स्टॉर्म्स और डाउनस्ट्रीम आउटेज को संभालें।

प्रत्येक लेयर की सीमित क्षमता होती है: SDK मेमोरी, एजेंट डिस्क, गेटवे कनेक्शन, स्ट्रीम रिटेंशन, प्रोसेसर कन्करेंसी, इंडेक्स राइट कतारें और क्वेरी थ्रेड्स। सिस्टम retry-after, छोटे बैचों, रोके गए कंज्यूमर्स और प्राथमिकता कतारों के माध्यम से दबाव का प्रसार करता है। जब एजेंट डिस्क अपनी सीमा के करीब पहुँचती है, तो यह पहले पॉलिसी के अनुसार डीबग लॉग्स का सैंपल लेती है और ड्रॉप की गई क्लास के अनुसार लोकल काउंटर्स रिकॉर्ड करती है। ऑडिट इवेंट्स एक अलग आरक्षित पूल का उपयोग करते हैं या एक स्पष्ट बिजनेस विफलता पॉलिसी को ट्रिगर करते हैं।

OpenTelemetry Collector ट्रबलशूटिंग गाइडेंस में कहा गया है कि एक अनुपलब्ध डेस्टिनेशन या एक छोटा Collector दोनों डेटा ड्रॉप का कारण बन सकते हैं। सेंडिंग कतारें और पुनः प्रयास अस्थायी विफलताओं को कवर करते हैं, लेकिन एक बहुत बड़ी कतार मेमोरी दबाव भी बना सकती है। इसलिए "रीट्राय सक्षम करें" अपने आप में एक विश्वसनीयता योजना नहीं है। कतार उपयोग, सबसे पुराने इवेंट की उम्र, अस्वीकृतियों, स्थायी विफलताओं और प्रोसेस मेमोरी की निगरानी करें, और क्षमता समाप्त होने से पहले अलर्ट करें।

यदि इंडेक्स क्लस्टर अनुपलब्ध है, तो ड्यूरेबल स्ट्रीम डेटा स्वीकार करना जारी रखती है, और रॉ-आर्काइव व इंडेक्स कंज्यूमर्स स्वतंत्र रूप से आगे बढ़ते हैं। रिकवरी के दौरान, इंडेक्स कंज्यूमर्स टेनेंट निष्पक्षता और रीप्ले सीमाओं के साथ कैच-अप करते हैं ताकि वे नए रीस्टोर किए गए क्लस्टर को फिर से ओवरलोड न करें। जब इंडेक्सिंग में देरी होती है, तो UI सर्च फ्रेशनेस वॉटरमार्क और गायब अंतराल प्रदर्शित करता है। उपयोगकर्ताओं को "कोई खोज परिणाम नहीं" का अर्थ "कोई लॉग मौजूद नहीं है" के रूप में नहीं समझना चाहिए।

चरण 8: सुरक्षा, गोपनीयता और विलोपन चक्र को पूरा करें।

संवेदनशील-डेटा का सबसे अच्छा नियंत्रण मान उत्पन्न करने से बचना है। SDK स्ट्रक्चर्ड-फ़ील्ड अनुमतियां (allowlists) प्रदान करते हैं। एजेंट सामान्य टोकन, पासवर्ड, कुकी और व्यक्तिगत-डेटा पैटर्न को रिडैक्ट करते हैं। गेटवे सेंट्रल ड्यूरेबल स्ट्रीम से पहले अनिवार्य नियम लागू करता है, और बाद के प्रोसेसर्स सिमेंटिक स्कीमा-आधारित रिडैक्शन करते हैं और फेल्ड इवेंट्स को क्वारंटाइन में भेजते हैं। एक रॉ बॉडी केवल इसलिए सुरक्षा को बायपास नहीं कर सकती क्योंकि यह केवल एक आर्काइव में जाती है।

ट्रांसपोर्ट mTLS या शॉर्ट-लिव्ड वर्कलोड पहचान का उपयोग करता है, और डेटा को एनवायरनमेंट या विनियमित-टेनेंट कुंजी सीमाओं के साथ रेस्ट (at rest) पर एन्क्रिप्ट किया जाता है। RBAC टेनेंट, एनवायरनमेंट, सर्विस, फ़ील्ड्स और समय सीमाओं को प्रतिबंधित करता है। क्वेरीज़, एक्सपोर्ट्स, रिटेंशन परिवर्तन और लीगल होल्ड्स इम्यूटैबल एक्सेस-ऑडिट इवेंट्स उत्पन्न करते हैं। अत्यधिक संवेदनशील फ़ील्ड्स फ़ील्ड एन्क्रिप्शन का उपयोग कर सकते हैं या पूरी तरह से हटाए जा सकते हैं; उन्हें UI में छिपाना पर्याप्त नहीं है।

विलोपन हॉट इंडेक्स, वार्म टियर्स, ऑब्जेक्ट पार्टीशन्स, कैश और एक्सपोर्ट प्रतियों में एक ट्रैक करने योग्य वर्कफ़्लो है। जब ऑडिट रिटेंशन किसी प्राइवेसी-विलोपन अनुरोध के साथ टकराव करता है, तो उत्पाद और कानूनी नीति को प्राथमिकता, अपवाद और लीगल होल्ड्स को परिभाषित करना चाहिए। सिस्टम उस स्पष्ट नीति को निष्पादित करता है; यह विलोपन दायित्व से बचने के लिए "लॉग्स इम्यूटैबल हैं" का उपयोग नहीं कर सकता है।

चरण 9: मेट्रिक्स और फ़ॉल्ट इंजेक्शन के साथ सिस्टम को साबित करें।

मुख्य मेट्रिक्स में निर्माण से गेटवे तक, गेटवे से ड्यूरेबल स्ट्रीम तक, स्ट्रीम से आर्काइव तक, और स्ट्रीम से सर्च विजिबिलिटी तक p50/p95/p99 शामिल हैं; प्रत्येक चरण पर कतार उपयोग, सबसे पुराने-इवेंट की उम्र, रीट्राय और ड्रॉप्स; टेनेंट इनजेशन, थ्रॉटलिंग, फ़ील्ड कार्डिनैलिटी और लागत; इंडेक्स अस्वीकृति, मैपिंग वृद्धि, स्कैन किए गए बाइट्स, क्वेरी टाइमआउट, रद्दीकरण और कैश हिट; रिडैक्शन विफलताएं, ऑथराइजेशन अस्वीकृति, और आर्काइव पुनर्प्राप्ति सफलता।

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

फ़ॉल्ट परीक्षणों में 15 मिनट के लिए 3x लॉग स्टॉर्म, 30 मिनट का सर्च आउटेज, ऑब्जेक्ट-स्टोरेज थ्रॉटलिंग, एक अवेलेबिलिटी ज़ोन का नुकसान, एक हॉट टेनेंट, एक हाई-कार्डिनैलिटी फ़ील्ड अटैक, एक अमान्य स्कीमा, सोर्स क्लॉक स्क्यू, संवेदनशील-डेटा इंजेक्शन, एक भरी हुई एजेंट डिस्क, डुप्लीकेट बैच, स्ट्रीम रीप्ले और आर्काइव्स से एक हॉट इंडेक्स का पुनर्निर्माण शामिल है। महत्वपूर्ण दावे यह हैं कि ऑडिट इवेंट्स नीति के अनुसार पुनर्प्राप्त करने योग्य बने रहें, प्रत्येक सामान्य-लॉग ड्रॉप में टेनेंट, क्लास, समय और गणना के लिए सबूत हों, और उपयोगकर्ता व अलर्ट डिग्रेडेड सर्च फ्रेशनेस देख सकें।

उच्च-गुणवत्ता वाला नमूना उत्तर (High-Quality Sample Answer)

“मैं सबसे पहले ड्यूरेबल एक्सेप्टेंस को सर्च विजिबिलिटी से अलग करूँगा। एप्लिकेशंस stdout या एक एसिंक्रोनस SDK में लिखती हैं, और एक नोड एजेंट बैचिंग, रिडैक्शन और सीमित डिस्क बफरिंग को संभालता है, ताकि लॉगिंग आउटेज सामान्य बिजनेस रिक्वेस्ट्स को सिंक्रोनस रूप से ब्लॉक न करे। रीजनल गेटवे वर्कलोड पहचान से टेनेंट प्राप्त करता है, कोटा और प्रारूप नियमों को लागू करता है, फिर बैच को अवेलेबिलिटी ज़ोन में रेप्लिकेट की गई ड्यूरेबल स्ट्रीम में कमिट करता है। वह केंद्रीय स्वीकृति बिंदु है। सर्च इंडेक्स और ऑब्जेक्ट आर्काइव्स एसिंक्रोनस रूप से डेटा कंज्यूम करते हैं।

इवेंट्स में इवेंट समय, ऑब्ज़र्व्ड समय, टेनेंट, सर्विस, एनवायरनमेंट, इंस्टेंस, सेवेरिटी, बॉडी, traceId, spanId, स्कीमा वर्ज़न और संवेदनशीलता के लिए स्टेबल टॉप-लेवल फ़ील्ड्स होते हैं। मनमाने एट्रिब्यूट्स डिफ़ॉल्ट रूप से स्टोर किए जाते हैं। वास्तविक क्वेरी मूल्य वाले केवल स्टेबल, सही टाइप वाले फ़ील्ड ही इंडेक्स में प्रवेश करते हैं, जिससे हाई-कार्डिनैलिटी एट्रिब्यूट्स मैपिंग और इंडेक्स वृद्धि का कारण नहीं बनते हैं। डिलीवरी एट-लीस्ट-वन्स है। एजेंट एक स्टेबल eventId के साथ पुनः प्रयास करता है, और इंडेक्स राइट्स idempotent होते हैं, हालांकि आर्काइव्स पहचान योग्य डुप्लीकेट्स को बनाए रख सकते हैं।

ऑब्जेक्ट स्टोरेज दोबारा चलाए जा सकने वाले (replayable) दीर्घकालिक रॉ रिकॉर्ड्स रखता है, जबकि हॉट सर्च टियर केवल हालिया, सर्च करने योग्य डेटा रखता है। प्रश्नों के लिए एक विश्वसनीय टेनेंट और समय सीमा की आवश्यकता होती है, जो हॉट, वार्म और आर्काइव टियर्स में रूट होते हैं, और स्कैन किए गए बाइट्स, कन्करेंसी और परिणाम आकार को सीमित करते हैं। व्यापक ऐतिहासिक फ़ुल-टेक्स्ट सर्च और एक्सपोर्ट्स एसिंक्रोनस जॉब्स बन जाते हैं। छोटे टेनेंट्स इंडेक्स साझा करते हैं और बड़े टेनेंट्स को अलग किया जा सकता है, लेकिन इनजेस्ट, बैकलॉग, फ़ील्ड और क्वेरी कोटा हमेशा टेनेंट द्वारा लागू होते हैं।

स्थिर अवस्था में, रॉ इनजेशन 600 MB/s या 51.84 TB/दिन है। यदि डाउनस्ट्रीम प्रोसेसिंग स्थिर क्षमता पर बनी रहती है, तो 15 मिनट का 3x बर्स्ट लगभग 1.08 TB का बैकलॉग जोड़ता है। 7 दिनों के लिए केवल 20% इंडेक्स करने पर भी इंडेक्स ओवरहेड से पहले लगभग 72.6 TB उत्पन्न होता है, जबकि 90 दिनों का रॉ आर्काइव कम्प्रेशन से पहले लगभग 4.67 PB होता है। इसलिए सेलेक्टिव इंडेक्सिंग, क्लास-आधारित रिटेंशन और टियरिंग अनिवार्य हैं।

विफलता के दौरान, ड्यूरेबल स्ट्रीम छोटे बैकलॉग को संभालती है और आर्काइव व इंडेक्स कंज्यूमर्स स्वतंत्र रूप से ठीक हो जाते हैं। प्रत्येक बफ़र सीमित है। सिस्टम पहले ऑडिट और एरर इवेंट्स को सुरक्षित रखता है, पहले डीबग इवेंट्स का सैंपल लेता है, और मॉनिटरिंग व UI में ड्रॉप्स, सबसे पुराने-मैसेज की उम्र और सर्च फ्रेशनेस वॉटरमार्क को दिखाता है। अंत में, मैं प्रोड्यूसर, स्ट्रीम, इंडेक्स और आर्काइव के माध्यम से एक यूनिक कैनरी चलाऊंगा और यह साबित करने के लिए कि कोई छिपा हुआ नुकसान नहीं है और इंडेक्स को आर्काइव्स से फिर से बनाया जा सकता है, 3x ट्रैफ़िक, डाउनस्ट्रीम आउटेज, हाई-कार्डिनैलिटी फ़ील्ड्स और डिस्क समाप्ति को इंजेक्ट करूँगा।”

सामान्य गलतियाँ (Common Mistakes)

• एप्लिकेशन से रिमोट लॉगिंग API को सिंक्रोनस रूप से कॉल करना → एक लॉगिंग आउटेज बिजनेस रिक्वेस्ट्स को नुकसान पहुंचाता है

→ सीमित बफरिंग और स्पष्ट डिग्रेडेशन के साथ एक लोकल एसिंक्रोनस एजेंट में लिखें।

• केवल सर्च-क्लस्टर राइट के बाद स्वीकार (acknowledge) करना → इंडेक्स मेंटेनेंस हर प्रोड्यूसर पर बैकप्रेशर डालती है

→ रेप्लिकेटेड ड्यूरेबल स्ट्रीम में कमिट करने के बाद स्वीकार करें।

• प्रत्येक JSON फ़ील्ड को डायनेमिक रूप से इंडेक्स करना → हाई कार्डिनैलिटी मैपिंग एक्सप्लोज़न और अनियंत्रित लागत पैदा करती है

→ केवल स्टेबल अनुमत (allowlisted) फ़ील्ड्स को इंडेक्स करें।

• प्रति टेनेंट आईडी एक स्ट्रीम पार्टीशन का उपयोग करना → एक बड़ा टेनेंट सिंगल-पार्टीशन हॉटस्पॉट बन जाता है

→ उचित होने पर डेडिकेटेड पूल के साथ, टेनेंट और सोर्स से वर्चुअल पार्टीशन्स का उपयोग करें।

• रैंडम पार्टीशनिंग के बाद ग्लोबल ऑर्डर का दावा करना → क्लॉक्स और पैरेलल सोर्सेज इसे प्रदान नहीं कर सकते

→ सोर्स-लोकल क्रम को सुरक्षित रखें और एक ऑब्ज़र्व्ड टाइमस्टैम्प रखें।

• डुप्लीकेट्स को छिपाने के लिए एक्ज़ैक्टली-वन्स का उपयोग करना → खोए हुए उत्तर और रीप्ले अभी भी होते हैं

→ एट-लीस्ट-वन्स डिलीवरी, स्टेबल eventId और idempotent राइट्स का उपयोग करें।

• यह मान लेना कि असीमित कतार नुकसान को रोकती है → डिस्क, मेमोरी और रिटेंशन अंततः भर जाते हैं

→ क्षमता सीमाएं निर्धारित करें, सबसे पुरानी उम्र की निगरानी करें, क्लासों को प्राथमिकता दें, और ड्रॉप साक्ष्य बनाए रखें।

• तूफान के दौरान सभी लॉग्स का समान रूप से सैंपल लेना → ऑडिट साक्ष्य भी खारिज हो जाते हैं

→ लॉग क्लास द्वारा विश्वसनीयता और डिग्रेडेशन को अलग-अलग परिभाषित करें।

• यह वादा करना कि प्रत्येक क्वेरी 2 सेकंड में समाप्त हो जाती है → एक 90-दिवसीय फ़ुल-टेक्स्ट स्कैन इंटरएक्टिव क्लस्टर को नुकसान पहुंचाता है

→ सेलेक्टिव हॉट क्वेरीज़ को एसिंक्रोनस ऐतिहासिक स्कैन से अलग करें।

• खाली UI परिणाम को इस बात का प्रमाण मानना कि कोई लॉग मौजूद नहीं है → इंडेक्स लैग इंसिडेंट के सबूत छुपाता है

→ वॉटरमार्क, आंशिक परिणाम और गायब विंडो दिखाएं।

• केवल हॉट इंडेक्स को हटाना → आर्काइव्स, कैश और एक्सपोर्ट्स में अभी भी संवेदनशील मान होते हैं

→ सभी प्रतियों में एक ऑडिट करने योग्य विलोपन वर्कफ़्लो का उपयोग करें।

• केवल यह निगरानी करना कि क्या Collector प्रक्रिया जीवित है → एक स्वस्थ प्रक्रिया अभी भी डेटा छोड़ सकती है

→ स्टेज काउंट्स का मिलान करें और कतारों, अस्वीकृतियों और स्थायी विफलताओं की निगरानी करें।

अनुवर्ती प्रश्न और उत्तर (Follow-Up Questions and Responses)

अनुवर्ती 1: एजेंट्स को सीधे सर्च क्लस्टर में क्यों नहीं लिखने दिया जाए?

यह एक छोटे आंतरिक टूल के लिए उचित है क्योंकि इसमें कम घटक और सीधी सर्च ताजगी होती है। इस पैमाने पर, सर्च-शार्ड परिवर्तन, मैपिंग विफलताएं और राइट अस्वीकृति 100,000 सोर्सेज में फैल जाएगी। एक ड्यूरेबल स्ट्रीम एक एक्नॉलेजमेंट सीमा बनाती है, बर्स्ट को संभालती है, कंज्यूमर्स को स्वतंत्र रूप से ठीक होने देती है, और रीप्ले का समर्थन करती है। इसके लिए अतिरिक्त संचालन, डुप्लीकेट्स और एसिंक्रोनस डिले की लागत आती है। यदि मापा गया पैमाना छोटा है, तो केवल आरेख के लिए ब्रोकर जोड़ने के बजाय सीधा रास्ता चुनें।

अनुवर्ती 2: क्या होगा यदि किसी फ़ील्ड में अचानक लाखों अलग-अलग मान आ जाएं?

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

अनुवर्ती 3: क्या होता है जब ड्यूरेबल स्ट्रीम और लोकल स्पूल दोनों भरे हों?

एक सीमित सिस्टम अनंत बर्स्ट की गारंटी नहीं दे सकता। एजेंट लॉग क्लास द्वारा क्षमता आरक्षित करता है: ऑडिट इवेंट्स सबसे मजबूत चैनल का उपयोग करते हैं, एरर्स सूचनात्मक इवेंट्स से ऊपर होते हैं, और डीबग लॉग्स का पहले सैंपल लिया जाता है या उन्हें ड्रॉप किया जाता है। प्रत्येक ड्रॉप को स्थानीय रूप से गिना जाता है और रिकवरी के बाद रिपोर्ट किया जाता है। यदि किसी व्यावसायिक संचालन के लिए किसी विशेष ऑडिट इवेंट का ड्यूरेबल होना आवश्यक है, तो संचालन स्पष्ट रूप से विफल हो सकता है या स्थानीय ट्रांसेक्शनल आउटबॉक्स का उपयोग कर सकता है। एक सामान्य डीबग कॉल को पूरे एप्लिकेशन को हमेशा के लिए ब्लॉक नहीं करना चाहिए।

अनुवर्ती 4: आप ऑब्जेक्ट स्टोरेज से सर्च इंडेक्स का पुनर्निर्माण कैसे करते हैं?

आर्काइव ऑब्जेक्ट्स में स्कीमा वर्ज़न, समय पार्टीशन, टेनेंट, चेकसम और एक मैनिफ़ेस्ट शामिल होता है। एक रीबिल्ड जॉब एक टेनेंट और विंडो का चयन करता है, मैनिफ़ेस्ट को पढ़ता और सत्यापित करता है, वर्तमान मैपिंग के साथ रिकॉर्ड्स को ट्रांसफ़ॉर्म करता है, और eventId द्वारा idempotent रूप से एक नए इंडेक्स में लिखता है। यह किसी उपनाम (alias) या रूट को परमाणु रूप से बदलने से पहले काउंट्स, समय सीमाओं और कैनरीज़ की तुलना करता है। रीबिल्ड ट्रैफ़िक का एक अलग कोटा होता है ताकि यह रीयल-टाइम इंडेक्सिंग को प्रभावित न करे।

अनुवर्ती 5: आप एक टेनेंट की क्वेरी को सभी को नुकसान पहुँचाने से कैसे रोकते हैं?

शेड्यूलर कन्करेंसी, CPU समय, स्कैन किए गए बाइट्स और लौटाए गए रो के लिए टेनेंट टोकन बकेट बनाए रखता है और वेटेड फेयर क्यूइंग का उपयोग करता है। इंटरएक्टिव क्वेरीज़ एक्सपोर्ट्स से ऊपर होती हैं, और महंगे काम को रद्द किया जा सकता है या एसिंक्रोनस रूप से स्थानांतरित किया जा सकता है। शेयर्ड कैश कीज़ में टेनेंट और अनुमति सारांश शामिल होते हैं। बड़े या अत्यधिक विनियमित टेनेंट्स आइसोलेटेड इंडेक्स पूल प्राप्त कर सकते हैं, लेकिन बाधा को मापने के बाद ही आइसोलेट करें ताकि छोटे टेनेंट्स अत्यधिक छोटे शार्ड्स न बनाएं।

अनुवर्ती 6: ऑडिट लॉग्स को एक अलग पॉलिसी की आवश्यकता क्यों है?

ऑडिट लॉग्स यह साबित करने के लिए मौजूद हैं कि किसने, क्या और कब किया। सैंपलिंग, म्यूटेबल कंटेंट और सामान्य व्यवस्थापक विलोपन उस उद्देश्य को विफल कर देंगे। उन्हें सख्त स्कीमा, प्रमाणित स्रोत, अखंडता जांच, इम्यूटैबल आर्काइव्स, प्रतिबंधित क्वेरीज़ और एक्सेस ऑडिटिंग की आवश्यकता होती है। वे अभी भी प्राइवेसी विलोपन और लीगल-होल्ड पॉलिसी का पालन करते हैं, इसलिए "इम्यूटैबल" का अर्थ है कि सामान्य रास्ते उन्हें बदल नहीं सकते हैं, न कि यह कि एक अधिकृत कम्प्लायंस वर्कफ़्लो कभी कार्य नहीं कर सकता है।

अनुवर्ती 7: आप इस डिज़ाइन को विभिन्न क्षेत्रों (regions) में कैसे विस्तारित करेंगे?

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

अनुवर्ती 8: आप कैसे साबित करते हैं कि सिस्टम चुपचाप लॉग नहीं खो रहा है?

प्रत्येक बैच सोर्स काउंट और चेकसम रिकॉर्ड करता है। प्रत्येक चरण स्वीकृत, डुप्लीकेट, अस्वीकृत, स्थायी रूप से विफल और सफल गणना उत्सर्जित करता है। एक अद्वितीय कैनरी एजेंट, गेटवे, ड्यूरेबल स्ट्रीम, इंडेक्स और आर्काइव को लगातार पार करती है। समाधान eventId द्वारा स्पष्ट किए गए डुप्लीकेट्स और एक स्पष्ट कोटा नीति द्वारा समझाए गए ड्रॉप्स की अनुमति देता है। कोई भी अस्पष्ट अंतर एक इंसिडेंट है। फिर 30 मिनट के लिए इंडेक्सिंग बंद करें और इसे रिकवर करें, यह सत्यापित करते हुए कि केवल यह जांचने के बजाय कि प्रोसेस फिर से शुरू हुई है या नहीं, मैसेज की उम्र कम होती है, कैनरीज़ अंतर को भरती हैं, और UI फ्रेशनेस वॉटरमार्क ठीक हो जाता है।