ट्रेसिंग: यह क्या है, सिद्धांत और डेटा संग्रह

निगरानी में ट्रेसिंग क्या है

ट्रेसिंग वितरित निरीक्षण की एक विधि है जहां प्रत्येक आने वाले अनुरोध को सिस्टम के सभी सेवाओं और घटकों के माध्यम से ट्रैक किया जाता है। मीट्रिक के विपरीत, जो समग्र मान दिखाते हैं (औसत प्रतिक्रिया समय, त्रुटि गणना), ट्रेसिंग एक विशिष्ट अनुरोध का पूरा संदर्भ संरक्षित करता है।

प्रसंस्करण का प्रत्येक चरण — डेटाबेस कॉल, किसी अन्य माइक्रोसर्विस के लिए HTTP अनुरोध, पृष्ठभूमि कार्य का निष्पादन — एक टाइमस्टैम्प, स्थिति और विशेषताओं के साथ एक अलग इकाई के रूप में रिकॉर्ड किया जाता है। Google Dapper (2010 का मूल प्रकाशन) के अनुसार, ट्रेसिंग वितरित प्रणालियों में एक एकल कॉल की सटीकता के साथ देरी का पता लगाने की अनुमति देता है।

ट्रेसिंग विशेष रूप से मोबाइल एप्लिकेशन के लिए महत्वपूर्ण है जहां बैकएंड दर्जनों माइक्रोसर्विसेज से बना होता है। एक उपयोगकर्ता क्रिया — जैसे खाते में लॉग इन करना — API Gateway, प्रमाणीकरण सेवा, डेटाबेस और Push सेवा से गुज़र सकता है। ट्रेसिंग के बिना, यह निर्धारित करना लगभग असंभव है कि कौन सा घटक प्रतिक्रिया को धीमा कर रहा है।

Spans और traces: मूल डेटा संरचना

ट्रेसिंग की मूल इकाई span है। प्रत्येक span एक तार्किक संचालन का प्रतिनिधित्व करता है: एक HTTP अनुरोध, SQL क्वेरी, gRPC कॉल, JSON सीरियलाइज़ेशन। एक span में एक अद्वितीय पहचानकर्ता, मूल पहचानकर्ता, संचालन नाम, आरंभ समय, अवधि, स्थिति और विशेषताओं का एक सेट होता है।

एक trace में spans का पदानुक्रम

एक ही मूल अनुरोध से संबंधित सभी spans एक trace में समूहित होते हैं। मूल span प्रवेश बिंदु का प्रतिनिधित्व करता है — मोबाइल क्लाइंट से API तक एक HTTP अनुरोध। चाइल्ड spans एक पेड़ बनाते हैं, जहां प्रत्येक span parent_span_id फ़ील्ड के माध्यम से अपने मूल को संदर्भित करता है।

एक trace की अवधि सभी spans के अद्वितीय समय खंडों की अवधियों के योग के बराबर होती है। यदि दो चाइल्ड spans समानांतर में निष्पादित होते हैं, तो उनका समय जोड़ा नहीं जाता — यह समानांतर माइक्रोसर्विस कॉल के कारण होने वाली देरी का सही ढंग से विश्लेषण करने के लिए महत्वपूर्ण है।

Span विशेषताएँ और घटनाएँ

प्रत्येक span में विशेषताएँ हो सकती हैं — मेटा-जानकारी के साथ कुंजी-मूल्य जोड़े: अनुरोध URL, उपयोगकर्ता ID, API संस्करण, होस्ट नाम। विशेषताओं का उपयोग ट्रेस को फ़िल्टर और समूहित करने के लिए किया जाता है। विशेषताओं के अलावा, spans घटनाओं का समर्थन करते हैं — पाठ्य विवरण के साथ टाइमस्टैम्प, जैसे "कैश मिस" या "कनेक्शन पुनः प्रयास"।

वितरित ट्रेसिंग कैसे काम करता है

वितरित ट्रेसिंग उन spans को जोड़ने की समस्या को हल करता है जो विभिन्न प्रक्रियाओं और विभिन्न मशीनों पर बनाए जाते हैं। तंत्र संदर्भ प्रसारण पर आधारित है: जब सेवा A सेवा B को कॉल करती है, तो बाहर जाने वाले अनुरोध में वर्तमान trace ID और मूल span ID वाला एक हेडर जोड़ा जाता है।

मानक संदर्भ प्रसारण प्रोटोकॉल W3C Trace Context (traceparent और tracestate हेडर) और Zipkin B3 (X-B3-TraceId, X-B3-SpanId हेडर) हैं। W3C Trace Context को 2021 में W3C कंसोर्टियम द्वारा एक मानक के रूप में अपनाया गया था और यह सभी प्रमुख टेलीमेट्री प्रदाताओं द्वारा समर्थित है।

अनुरोध प्राप्त करने पर, सेवा B हेडर से trace_id निकालता है और उस trace_id के साथ एक चाइल्ड span बनाता है। इस प्रकार, अनुरोध पूरा होने के बाद, विभिन्न सेवाओं के सभी spans कलेक्टर की ओर एक single trace में संयुक्त हो जाते हैं। इसके लिए आवश्यक है कि प्रत्येक सेवा एक ही ट्रेसिंग लाइब्रेरी से इंस्ट्रूमेंटेड हो।

माइक्रोसर्विसेज में संदर्भ प्रसारण

मोबाइल डेवलपमेंट में, संदर्भ प्रसारण केवल बैकएंड को ही नहीं बल्कि क्लाइंट-सर्वर इंटरैक्शन को भी कवर करता है। एक मोबाइल एप्लिकेशन प्रत्येक API अनुरोध के हेडर में trace_id भेज सकता है, जिससे क्लाइंट क्रिया को सर्वर-साइड प्रोसेसिंग से जोड़ा जा सकता है। iOS और Android के लिए OpenTelemetry SDK HTTP क्लाइंट के माध्यम से स्वचालित निर्माण और ट्रेस संदर्भ के प्रसारण का समर्थन करता है।

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

प्रस्तुत Kotlin इंटरसेप्टर सर्वर पर प्रत्येक HTTP अनुरोध के लिए एक span बनाता है। मूल संदर्भ Context.current() के माध्यम से कॉल करने वाले कोड से प्रसारित होता है, जो क्लाइंट-साइड ट्रेसिंग को सर्वर-साइड ट्रेसिंग से जोड़ने की अनुमति देता है।

OpenTelemetry के माध्यम से ट्रेसिंग का कार्यान्वयन

OpenTelemetry ट्रेस डेटा संग्रह के लिए वास्तविक मानक है। यह spans उत्पन्न करने के लिए एक एकीकृत API, लोकप्रिय लाइब्रेरी का स्वचालित इंस्ट्रूमेंटेशन और विभिन्न बैकएंड में डेटा निर्यात करने के लिए एक लचीला तंत्र प्रदान करता है: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic।

स्वचालित इंस्ट्रूमेंटेशन

OpenTelemetry लोकप्रिय फ्रेमवर्क के लिए स्वचालित span निर्माण का समर्थन करता है: Spring Boot, Ktor, Flask, Express, gRPC। डेवलपर को केवल प्रोजेक्ट में एक निर्भरता जोड़ने की आवश्यकता होती है, और लाइब्रेरी स्वचालित रूप से इनकमिंग और आउटगोइंग अनुरोधों को इंटरसेप्ट करती है। Java के लिए ऑटो-इंस्ट्रूमेंटेशन एक javaagent का उपयोग करता है जो स्रोत कोड को बदले बिना फ्लाई पर बाइटकोड को संशोधित करता है।

मोबाइल प्लेटफॉर्म के लिए, OpenTelemetry Swift SDK और Kotlin SDK प्रदान करता है। वे नेटवर्क अनुरोधों (URLSession, OkHttp), डेटाबेस संचालन (CoreData, Room) और पृष्ठभूमि कार्यों के लिए स्वचालित रूप से spans बनाते हैं। डेवलपर व्यावसायिक तर्क के लिए कस्टम spans जोड़ सकता है।

डेटा निर्यात

एकत्रित spans को OTLP (OpenTelemetry Protocol) के माध्यम से कलेक्टर को भेजा जाता है। कलेक्टर डेटा को बफर, फ़िल्टर और एक या अधिक भंडारण प्रणालियों में अग्रेषित कर सकता है। OpenTelemetry दस्तावेज़ीकरण के अनुसार, gRPC निर्यात का उपयोग करते समय span निर्माण से डैशबोर्ड में इसके प्रदर्शन तक विशिष्ट विलंबता 2–5 सेकंड है।

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Swift कोड नेटवर्किंग लेयर के स्वचालित इंस्ट्रूमेंटेशन को सक्रिय करता है और उपयोगकर्ता प्रोफ़ाइल प्राप्ति संचालन के लिए एक कस्टम span बनाता है। user.id विशेषता बाद में किसी विशिष्ट उपयोगकर्ता द्वारा ट्रेस को फ़िल्टर करने की अनुमति देती है।

ट्रेस सैंपलिंग रणनीतियाँ

उच्च-लोड प्रणालियों में, प्रत्येक अनुरोध को ट्रेस करना असंभव है — यह भंडारण और नेटवर्क पर अस्वीकार्य भार पैदा करता है। सैंपलिंग केवल ट्रेस के एक भाग को सहेजकर इस समस्या को हल करता है। रणनीति का चुनाव सीधे डेटा पूर्णता और बुनियादी ढांचे की लागत को प्रभावित करता है।

हेड-बेस्ड सैंपलिंग

ट्रेस को सहेजने का निर्णय इसके निर्माण के समय — मूल span में लिया जाता है। सबसे सरल और सामान्य दृष्टिकोण: अनुरोधों का एक निश्चित प्रतिशत (जैसे, 5%) सहेजा जाता है, बाकी छोड़ दिए जाते हैं। नुकसान — यह गारंटी नहीं दी जा सकती कि दुर्लभ त्रुटियां कैप्चर की जाएंगी। OpenTelemetry में Probability sampler 0.0 से 1.0 तक संभाव्यता सेटिंग का समर्थन करता है।

टेल-बेस्ड सैंपलिंग

निर्णय ट्रेस के सभी spans के पूरा होने तक स्थगित किया जाता है। एक विश्लेषक मूल्यांकन करता है कि क्या ट्रेस में त्रुटियां, समय सीमा से अधिक या दिलचस्प विशेषताएं हैं, और तभी इसे सहेजता है। इस दृष्टिकोण के लिए कलेक्टर में सभी spans को बफर करने की आवश्यकता होती है, जिससे मेमोरी खपत बढ़ जाती है। Grafana Labs के अनुसार, दुर्लभ लेकिन महत्वपूर्ण त्रुटियों वाली प्रणालियों में "लागत प्रति उपयोगी डेटा" के मामले में टेल-बेस्ड सैंपलिंग 40–60% अधिक कुशल है।

ट्रेसिंग और लॉगिंग के बीच अंतर

लॉगिंग महत्व स्तर (info, warn, error) के साथ अलग-अलग घटनाओं को रिकॉर्ड करता है लेकिन उन्हें एक अनुरोध के संदर्भ में नहीं जोड़ता। ट्रेसिंग, इसके विपरीत, एक एंड-टू-एंड अनुरोध से संबंधित संचालन का एक संरचित वृक्ष बनाता है। व्यवहार में, ये दो दृष्टिकोण परस्पर अनन्य नहीं हैं बल्कि एक-दूसरे के पूरक हैं।

लॉग एक विशिष्ट त्रुटि के विस्तृत विश्लेषण के लिए प्रभावी हैं: डेवलपर सटीक संदेश, स्टैक ट्रेस और चर मान देखता है। ट्रेसिंग प्रश्न का उत्तर देता है "अनुरोध 5 सेकंड क्यों ले रहा है" — यह दिखाता है कि किस माइक्रोसर्विस या कॉल ने सबसे अधिक समय लिया। Honeycomb (2024) के अनुसार, ट्रेसिंग को लॉगिंग के साथ उपयोग करने वाली टीमें घटनाओं का मूल कारण 2.3 गुना तेजी से ढूंढती हैं।

आधुनिक दृष्टिकोण — ऑब्ज़र्वेबिलिटी — ट्रेसिंग, मीट्रिक और लॉग को एक एकल प्रणाली में जोड़ता है। OpenTelemetry इन तीन संकेतों के बीच सहसंबंध का समर्थन करता है: प्रत्येक span में संबंधित लॉग के लिंक हो सकते हैं, और मीट्रिक को विशिष्ट ट्रेस में ड्रिल डाउन करने के लिए trace_id से टैग किया जा सकता है।