Traces

Traces रिक्वेस्ट्स के पूरे पाथ को दर्शाते हैं जब वे एप्लिकेशन के अलग-अलग कंपोनेंट्स से होकर गुज़रते हैं।

Logs या metrics के विपरीत, traces एक से ज़्यादा एप्लिकेशन या सर्विस के इवेंट्स से बनते हैं, और इनमें सर्विसेज़ के बीच कनेक्शन का कॉन्टेक्स्ट होता है — जैसे रिस्पॉन्स लेटेंसी, सर्विस फ़ॉल्ट्स, रिक्वेस्ट पैरामीटर्स और मेटाडेटा।

सुझाव

Logs और traces में कॉन्सेप्ट में समानता है, लेकिन trace को क्रॉस-सर्विस कॉन्टेक्स्ट में देखा जाता है, जबकि logs आम तौर पर एक ही सर्विस या एप्लिकेशन के एग्ज़ीक्यूशन तक सीमित होते हैं।

सुझाव

आज के डेवलपर्स मॉड्यूलर और डिस्ट्रीब्यूटेड एप्लिकेशन बनाने की तरफ़ बढ़ रहे हैं। कुछ इन्हें Service Oriented Architecture कहते हैं, कुछ microservices। नाम चाहे जो हो, जब इन लूज़ली कपल्ड एप्लिकेशन में कुछ गड़बड़ होती है, तो सिर्फ़ logs या events देखकर इंसिडेंट का रूट कॉज़ ट्रैक करना काफ़ी नहीं होता। रिक्वेस्ट फ़्लो में पूरी विज़िबिलिटी ज़रूरी है — और यहीं traces काम आते हैं। ये कॉज़-एंड-इफ़ेक्ट से जुड़े इवेंट्स की सीरीज़ के ज़रिए एंड-टू-एंड रिक्वेस्ट फ़्लो दिखाते हैं और आपको वो विज़िबिलिटी देते हैं।

Traces ऑब्ज़र्वेबिलिटी का एक ज़रूरी स्तंभ हैं क्योंकि ये रिक्वेस्ट के सिस्टम में आने और जाने के फ़्लो की बुनियादी जानकारी देते हैं।

सुझाव

Traces के कॉमन यूज़ केसेज़ में परफ़ॉर्मेंस प्रोफ़ाइलिंग, प्रोडक्शन इश्यूज़ डिबग करना, और फ़ेलियर का रूट कॉज़ एनालिसिस शामिल है।

अपने सभी इंटीग्रेशन पॉइंट्स को इंस्ट्रुमेंट करें

जब आपके वर्कलोड का सारा कोड और फ़ंक्शनैलिटी एक ही जगह हो, तो सोर्स कोड देखकर आसानी से पता चलता है कि रिक्वेस्ट अलग-अलग फ़ंक्शन्स में कैसे पास होता है। सिस्टम लेवल पर आप जानते हैं कि ऐप किस मशीन पर चल रहा है, और कुछ गड़बड़ हो तो रूट कॉज़ जल्दी मिल जाता है। अब सोचिए एक microservices-बेस्ड आर्किटेक्चर में ऐसा करना — जहाँ अलग-अलग कंपोनेंट्स लूज़ली कपल्ड हैं और डिस्ट्रीब्यूटेड एनवायरनमेंट में चल रहे हैं। कई सिस्टम में लॉगिन करके हर इंटरकनेक्टेड रिक्वेस्ट के logs देखना — अगर नामुमकिन नहीं तो बेहद मुश्किल होगा।

यहीं ऑब्ज़र्वेबिलिटी मदद करती है। इंस्ट्रुमेंटेशन उस ऑब्ज़र्वेबिलिटी को बढ़ाने का एक अहम कदम है। सीधे शब्दों में, इंस्ट्रुमेंटेशन कोड की मदद से आपके एप्लिकेशन में इवेंट्स को मापना है।

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

जानकारी

एक सर्विस से दूसरी सर्विस के हर कनेक्शन को एक सेंट्रल कलेक्टर को traces भेजने के लिए इंस्ट्रुमेंट किया जाना चाहिए। इससे आप अपने वर्कलोड के उन हिस्सों में देख पाते हैं जो वरना दिखते नहीं।

जानकारी

ऑटो-इंस्ट्रुमेंटेशन एजेंट या लाइब्रेरी इस्तेमाल करने से एप्लिकेशन इंस्ट्रुमेंट करना काफ़ी हद तक ऑटोमेटेड हो सकता है।

ट्रांज़ैक्शन टाइम और स्टेटस ज़रूरी है — इसे मापें!

एक अच्छी तरह इंस्ट्रुमेंट किया गया एप्लिकेशन एंड-टू-एंड trace बना सकता है, जिसे इस तरह के वॉटरफ़ॉल ग्राफ़ में देखा जा सकता है:

या एक सर्विस मैप:

हर इंटरैक्शन का ट्रांज़ैक्शन टाइम और रिस्पॉन्स कोड मापना ज़रूरी है। इससे ओवरऑल प्रोसेसिंग टाइम कैलकुलेट करने और अपने SLA, SLO, या बिज़नेस KPI के कम्प्लायंस को ट्रैक करने में मदद मिलती है।

जानकारी

अपने इंटरैक्शन्स का रिस्पॉन्स टाइम और स्टेटस कोड समझकर और रिकॉर्ड करके ही आप ओवरऑल रिक्वेस्ट पैटर्न और वर्कलोड हेल्थ में कंट्रीब्यूट करने वाले फ़ैक्टर्स देख सकते हैं।

मेटाडेटा, एनोटेशन और लेबल — आपके सबसे अच्छे दोस्त

Traces एक यूनीक ID के साथ स्टोर किए जाते हैं। हर trace को spans या segments (आपकी टूलिंग के हिसाब से) में बाँटा जाता है जो रिक्वेस्ट के पाथ में हर स्टेप रिकॉर्ड करते हैं। एक span उन एंटिटीज़ को दिखाता है जिनसे trace इंटरैक्ट करता है। पैरेंट trace की तरह, हर span को एक यूनीक ID और टाइमस्टैम्प मिलता है और इसमें एक्स्ट्रा डेटा-मेटाडेटा भी हो सकता है। यह डिबगिंग में काम आता है क्योंकि यह बताता है कि प्रॉब्लम ठीक कब और कहाँ हुई।

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

जानकारी

नेमिंग कन्वेंशन वेंडर्स के बीच अलग हो सकते हैं, लेकिन हर trace को मेटाडेटा, लेबल, या एनोटेशन से एनरिच किया जा सकता है — और ये आपके पूरे वर्कलोड में सर्च करने योग्य होते हैं। इन्हें जोड़ने के लिए आपकी तरफ़ से कोड लिखना पड़ता है, लेकिन इससे आपके वर्कलोड की ऑब्ज़र्वेबिलिटी काफ़ी बढ़ जाती है।

चेतावनी

Traces logs नहीं हैं — अपने traces में शामिल मेटाडेटा के साथ संयम बरतें। Trace डेटा हाई सैंपल रेट के साथ भी फ़ोरेंसिक और ऑडिटिंग के लिए नहीं बना है।