डेटा इंजीनियरिंग इंटरव्यू: आप लेगेसी लॉग्स को OpenTelemetry Logs Data Model में कैसे माइग्रेट करेंगे?

प्रॉम्प्ट और दायरा

एक कंपनी अलग-अलग फील्ड नामों, टाइम प्रिसिजन और सेवेरिटी कन्वेंशनों के साथ एप्लिकेशन टेक्स्ट लॉग्स, कंटेनर stdout और लेगेसी JSON इवेंट्स उत्सर्जित करती है। वह ऐतिहासिक खोज को सुरक्षित रखते हुए और भ्रामक TraceId लिंक से बचते हुए OpenTelemetry Logs Data Model को अपनाना चाहती है। एक ऑफ़लाइन बैकफ़िल और रीयल-टाइम डुअल-राइट (dual-write) योजना डिज़ाइन करें।

OpenTelemetry Timestamp, ObservedTimestamp, TraceId, SpanId, SeverityNumber, Body, Resource और Attributes को अलग करता है। यह माइग्रेशन एक ट्रैसेबल डेटा कॉन्ट्रैक्ट है, न कि हर लाइन को Body में डालने का निर्णय। एक मजबूत उत्तर पार्सर विफलताओं, टाइम ज़ोन, डुप्लिकेट्स, संवेदनशील फ़ील्ड्स और रीप्ले वॉटरमार्क को संभालता है।

इंटरव्यूअर क्या मूल्यांकन करता है

• इवेंट टाइम, ऑब्जर्वेशन टाइम, रिसोर्स एट्रिब्यूट्स और इवेंट एट्रिब्यूट्स में अंतर करना।
• स्कीमा मैपिंग, वर्ज़न, अज्ञात-फ़ील्ड रिटेंशन और पार्स-विफलता पथ डिज़ाइन करना।
• TraceId, SpanId और रिक्वेस्ट आइडेंटिफ़ायर्स की सत्यता और वैकल्पिक स्थिति को सुरक्षित रखना।
• टेनेंट आइसोलेशन, रिडैक्शन, डुप्लिकेट्स, रीऑर्डरिंग और बैकफ़िल लागत को संभालना।
• केवल किसी ETL टूल का नाम लेने के बजाय रीप्ले करने योग्य, समाधान योग्य (reconcilable) क्वालिटी गेट्स प्रदान करना।

स्पष्टीकरण के लिए प्रश्न

1. क्या लेगेसी टाइमस्टैम्प लोकल, UTC या मिश्रित हैं, और क्या वे मिलीसेकंड या नैनोसेकंड प्रिसिजन वाले हैं?
2. किन स्रोतों में स्थिर स्कीमा हैं, और किनमें regex या सैंपल-आधारित पार्सिंग की आवश्यकता है?
3. क्या TraceId, SpanId और रिक्वेस्ट ID एप्लिकेशन द्वारा जनरेट किए जाते हैं या कलेक्टर्स द्वारा अनुमान लगाए जाते हैं?
4. क्या रॉ पेलोड को बनाए रखना ज़रूरी है, कितने समय के लिए, और उन्हें कौन पढ़ सकता है?
5. क्या बैकफ़िल और डुअल-राइट स्टोरेज और इंडेक्स साझा करते हैं, और क्वेरी में कितना विचलन (divergence) स्वीकार्य है?

30-सेकंड का उत्तर

मैं वर्ज़न किए गए मैपिंग कॉन्ट्रैक्ट्स बनाऊंगा और पार्स स्टेटस के साथ रॉ पेलोड को सुरक्षित रखूंगा। Timestamp इवेंट का समय है और ObservedTimestamp ऑब्जर्वेशन का समय है; Resource में सर्विस, होस्ट और टेनेंट जैसे स्थिर सोर्स तथ्य होते हैं, Attributes में इवेंट फ़ील्ड होते हैं, और Body में स्ट्रक्चर्ड व्यावसायिक सामग्री होती है। मैं केवल विश्वसनीय कॉन्टेक्स्ट से TraceId और SpanId भरूंगा। बैकफ़िल डुअल-राइट के साथ चलता है, मिलान (reconciliation) सोर्स और टाइम पार्टीशन का उपयोग करता है, और विफलताएं रीप्ले करने योग्य डेड लेटर्स में जाती हैं। गेट्स पार्स की सफलता, फ़ील्ड की पूर्णता, टाइम स्क्यू, डुप्लिकेट्स, रिडैक्शन हिट्स और क्वेरी समानता को कवर करते हैं।

स्टेप-बाय-स्टेप समाधान

1. सबसे पहले डेटा कॉन्ट्रैक्ट तय करें

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

{
  "timestamp": "2026-08-02T02:00:00.123Z",
  "observedTimestamp": "2026-08-02T02:00:00.800Z",
  "severityNumber": 17,
  "severityText": "ERROR",
  "body": {"message": "payment declined", "code": "CARD_DECLINED"},
  "resource": {"service.name": "checkout", "tenant.id": "t-7"},
  "attributes": {"region": "us-east-1"}
}

2. समय के सिमेंटिक्स को सुरक्षित रखें

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

3. Resource, Attributes और Body को मैप करें

Resource उस एंटिटी का वर्णन करता है जो लॉग्स जनरेट कर रही है, जैसे कि सर्विस, वर्ज़न, होस्ट, क्लस्टर और टेनेंट। Attributes किसी इवेंट इंस्टेंस का वर्णन करते हैं, जैसे कि रीजन, रिक्वेस्ट टाइप या एक्सपेरिमेंट ग्रुप। Body में स्ट्रक्चर्ड सामग्री या एक अनपार्स किया गया मैसेज होता है। फ़ील्ड्स को गलत जगह रखने से एग्रीगेशन, इंडेक्सिंग और लागत बदल जाती है, इसलिए मैपिंग में कारणों और डाउनस्ट्रीम उपभोक्ताओं को रिकॉर्ड किया जाना चाहिए।

4. सेवेरिटी और कॉन्टेक्स्ट को मैप करें

मूल SeverityText को बनाए रखते हुए लेगेसी WARN, ERR और संख्यात्मक स्तरों को SeverityNumber में मैप करें। TraceId, SpanId और TraceFlags को केवल तभी स्वीकार करें जब फॉर्मेट और इंजेक्शन पॉइंट विश्वसनीय हों। लापता कॉन्टेक्स्ट को कारण के साथ खाली रखें; कभी भी ट्रेस ID का मनगढ़ंत निर्माण न करें। रिक्वेस्ट ID एक सामान्य Attribute हो सकता है लेकिन इसे TraceId के रूप में प्रस्तुत नहीं किया जाना चाहिए।

5. डुअल-राइट और बैकफ़िल डिज़ाइन करें

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

6. विफलता, डुप्लिकेट्स और रीऑर्डरिंग को संभालें

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

7. आइसोलेशन, रिडैक्शन और लागत

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

8. क्वालिटी गेट्स और रोलबैक

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

एक मजबूत उत्तर का नमूना

मैं माइग्रेशन को कॉन्ट्रैक्ट, पार्सिंग, डुअल-राइट, बैकफ़िल, समाधान (reconciliation) और कटओवर में विभाजित करूंगा। प्रत्येक सोर्स को एक वर्ज़न वाला पार्सर और स्थिर इवेंट ID मिलता है। Timestamp इवेंट का समय है और ObservedTimestamp कलेक्शन का समय है। Resource सर्विस, होस्ट और टेनेंट के स्थिर तथ्यों को रखता है; Attributes इवेंट फ़ील्ड्स को रखते हैं; Body स्ट्रक्चर्ड सामग्री रखता है; SeverityNumber पुराने स्तरों को मैप करता है; TraceId केवल विश्वसनीय कॉन्टेक्स्ट से स्वीकार किया जाता है।

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

सामान्य गलतियां

• सब कुछ Body में डालना → डाउनस्ट्रीम में रिसोर्स और एट्रिब्यूट सिमेंटिक्स का नुकसान → डेटा मॉडल के अनुसार फ़ील्ड्स को मैप करें और अज्ञात को बनाए रखें।
• इवेंट टाइम को कलेक्शन टाइम से बदलना → बिज़नेस लेटेंसी को मापना असंभव हो जाता है → Timestamp और ObservedTimestamp दोनों को बनाए रखें।
• कॉन्टेक्स्ट गायब होने पर TraceId मनगढ़ंत बनाना → फ़र्ज़ी ट्रेस बनते हैं → इसे खाली रखें और कारण रिकॉर्ड करें।
• बिना मिलान (reconciliation) के डुअल-राइट करना → ऐतिहासिक और लाइव परिणाम समान साबित नहीं किए जा सकते → पोज़ीशन, इवेंट ID और टाइम विंडो द्वारा मिलान करें।
• पार्स विफलताओं को ड्रॉप करना → पार्सर सुधार के बाद भी इतिहास की मरम्मत नहीं की जा सकती → रीप्ले करने योग्य डेड लेटर्स का उपयोग करें।
• रिडैक्शन से पहले डेटा स्टोर करना → रॉ डेटा का एक्सपोज़र विंडो बड़ा होता है → नियंत्रित इनग्रेस पर रिडैक्ट करें और ओरिजिनल को अलग रखें।

फ़ॉलो-अप प्रश्न और उत्तर

क्या होगा यदि कोई इवेंट टाइमस्टैम्प नहीं है?

मिसिंग-टाइम मार्कर के साथ एक स्पष्ट फ़ॉलबैक के रूप में ObservedTimestamp का उपयोग करें। इसे बिज़नेस टाइम के रूप में प्रस्तुत न करें; क्वालिटी मेट्रिक्स में इसे अलग से रिपोर्ट करें।

आप कैसे साबित करेंगे कि TraceId मनगढ़ंत नहीं था?

केवल एप्लिकेशन SDK या नियंत्रित-प्रॉक्सी कॉन्टेक्स्ट पर भरोसा करें, फॉर्मेट और स्कोप को वैलिडेट करें, और समान नाम वाले क्लाइंट फ़ील्ड को एक सामान्य Attribute के रूप में मानें।

आप डुअल-राइट से डुप्लिकेट्स को कैसे संभालते हैं?

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

यदि माइग्रेशन के दौरान फ़ील्ड का अर्थ बदल जाता है तो क्या होगा?

पार्सर और स्कीमा वर्ज़न को आगे बढ़ाएं (bump करें), पुरानी मैपिंग और वर्ज़न मेटाडेटा को बनाए रखें, एक कम्पैटिबिलिटी विंडो की अनुमति दें, और दोनों वर्ज़न के खिलाफ डाउनस्ट्रीम क्वेरीज़ का परीक्षण करें।

रॉ पेलोड को क्यों बनाए रखें?

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