Microsoft की Foundry टीम ने अपने एजेंट फ्रेमवर्क में OpenTelemetry-आधारित ट्रेसिंग (tracing) जोड़ दी है, जिससे डेवलपर्स को विभिन्न प्रकार के LLM-संचालित एजेंटों के बीच एंड-टू-एंड निष्पादन (execution) देखने का एक तरीका मिल गया है।

मल्टी-एजेंट सिस्टम को लॉग फाइलों से अधिक की आवश्यकता क्यों है

एक विशिष्ट AI-संचालित इंसिडेंट-रिस्पॉन्स ड्रिल (incident-response drill) में एक कमांडर एजेंट का उपयोग किया जाता है जो कई विशेषज्ञ एजेंटों को संचालित करता है: एक लॉग्स को पार्स करता है, दूसरा मेट्रिक विसंगतियों (anomalies) का पता लगाता है, तीसरा लक्षणों को रनबुक्स (runbooks) से मिलाता है, और एक राउटर प्रत्येक सब-टास्क के लिए सबसे अच्छा लैंग्वेज मॉडल चुनता है। प्रत्येक विशेषज्ञ एक अलग मॉडल—जैसे, "gpt-5-mini" वेरिएंट—का उपयोग कर सकता है और अपने स्वयं के टूल्स को कॉल कर सकता है। जब कुछ गलत होता है, तो इंजीनियर अलग-थलग लॉग्स को देखते हैं जो यह तो दिखाते हैं कि प्रत्येक घटक ने क्या किया, लेकिन यह नहीं दिखाते कि वे सभी हिस्से एक साथ कैसे जुड़े हुए हैं।

एक एकीकृत ट्रेस (unified trace) के बिना, मूल कारण (root cause) एजेंटों के बीच डेटा के हस्तांतरण (hand-off) में छिपा रहता है। कमांडर एक ऐसा अनुरोध भेज सकता है जिसे लॉग-रीडर सही ढंग से संभालता है, फिर भी मेट्रिक विशेषज्ञ डेटा की गलत व्याख्या कर सकता है और गलत रनबुक का सुझाव दे सकता है। उस चेन को मैन्युअल रूप से डीबग करने में समय लगता है और त्रुटियों की संभावना बनी रहती है।

OpenTelemetry वर्कफ़्लो को एक साथ कैसे जोड़ता है

OpenTelemetry दो मुख्य अवधारणाओं को परिभाषित करता है: traces और spans। एक ट्रेस एक विशिष्ट पहचानकर्ता (unique identifier) है जो प्रवेश से लेकर अंतिम प्रतिक्रिया तक अनुरोध का अनुसरण करता है। एक स्पैन (span) उस ट्रेस के भीतर एक एकल ऑपरेशन—जैसे लैंग्वेज मॉडल को कॉल करना या टूल का उपयोग करना—को रिकॉर्ड करता है।

जब कोई एजेंट अनुरोध प्राप्त करता है, तो वह अनुरोध के मेटाडेटा से इनकमिंग Trace ID लेता है और एक चाइल्ड स्पैन बनाता है जो उसी ID को इनहेरिट (inherit) करता है। चाइल्ड स्पैन अपने शुरू होने का समय, अवधि, एट्रिब्यूट्स (मॉडल का नाम, उपयोग किया गया टूल) और किसी भी त्रुटि को लॉग करता है। यह प्रक्रिया प्रत्येक डाउनस्ट्रीम एजेंट के लिए दोहराई जाती है, जिससे एक ऐसा ट्री (tree) बनता है जो समग्र कार्य के तार्किक प्रवाह (logical flow) को दर्शाता है।

OpenTelemetry Baggage का भी समर्थन करता है, जो कस्टम की-वैल्यू पेयर्स (key-value pairs) के लिए एक हल्का कैरियर है। ट्रेस के शीर्ष पर बैगेज (baggage) के साथ "drill-id" या अन्य व्यावसायिक संदर्भ (business context) जोड़कर, प्रत्येक डाउनस्ट्रीम स्पैन स्वचालित रूप से उस पहचानकर्ता को इनहेरिट कर लेता है। इसके बाद एक स्पैन प्रोसेसर बैगेज को नियमित एट्रिब्यूट्स में बदल देता है, जिससे किसी विशेष इंसिडेंट ड्रिल से संबंधित सभी स्पैन को क्वेरी करना आसान हो जाता है।

नया ट्रेसिंग सरफेस कैसा दिखता है

इंस्ट्रूमेंटेशन (instrumentation) लागू होने के बाद, Azure Monitor (या कोई भी OpenTelemetry-संगत बैकएंड) एक विज़ुअल पदानुक्रम (visual hierarchy) प्रदर्शित करता है:

  • Agent name / ID – दिखाता है कि किस घटक ने ऑपरेशन किया।
  • Tool usage – रिकॉर्ड करता है कि किस बाहरी सेवा या फ़ंक्शन को कॉल किया गया था।
  • Model version – उपयोग किए गए सटीक LLM को लॉग करता है, जो मॉडल अपग्रेड के बाद रिग्रेशन (regressions) को ट्रैक करने के लिए उपयोगी है।
  • Token consumption – यह कैप्चर करता है कि मॉडल को कितने टोकन भेजे गए और कितने प्राप्त हुए, जिससे टीमों को लागत प्रबंधित करने में मदद मिलती है।
  • Latency / duration – यह उजागर करता है कि बाधाएं (bottlenecks) कहाँ आ रही हैं, चाहे वह मॉडल इन्फरेंस (inference) में हो या टूल I/O में।

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

AI-केंद्रित ऑपरेशन्स के लिए महत्व

  • रूट-कॉज़ एनालिसिस की गति – टीमें विफलता को ठीक उसी स्पैन तक ट्रैक कर सकती हैं जिसने त्रुटि दी थी, जिससे समाधान का औसत समय (mean time to resolution) कम हो जाता है।
  • लागत दृश्यता (Cost visibility) – टोकन काउंट लेटेंसी के साथ दिखाई देते हैं, जिससे फाइनेंस टीम क्लाउड बिल बढ़ने से पहले ही अनियंत्रित उपयोग का पता लगा सकती है।
  • परफॉरमेंस ट्यूनिंग – एजेंटों के बीच हाई-लेटेंसी स्पैन यह संकेत देते हैं कि कहाँ कैशिंग (caching), मॉडल चयन या टूल रीडिज़ाइन थ्रूपुट (throughput) को बढ़ा सकते हैं।

आगे क्या देखें

LangChain, OpenAI SDK या अन्य ऑर्केस्ट्रेशन लेयर्स पर बने प्रोजेक्ट्स GenAI के लिए समान सिमेंटिक कन्वेंशन (semantic conventions) अपना सकते हैं, जिससे ऐसे ट्रेसेस का मार्ग प्रशस्त होगा जो क्लाउड प्रोवाइडर्स और ऑन-प्रिमाइसेस डिप्लॉयमेंट के बीच प्रवाहित हो सकें।

संगठन बस अपने एजेंटों में OpenTelemetry SDK को सक्षम करते हैं और डेटा को Azure Monitor या किसी ओपन-सोर्स कलेक्टर को भेजते हैं।

निष्कर्ष

OpenTelemetry मल्टी-एजेंट AI सिस्टम को वह महत्वपूर्ण कड़ी (glue) प्रदान करता है जो बिखरे हुए लॉग्स को एक सुसंगत विवरण (coherent narrative) में बदल देता है। विभिन्न प्रकार के LLMs, राउटर और टूल कॉल्स के बीच एक एकल Trace ID को प्रसारित करके, डेवलपर्स ट्रेसिंग इंफ्रास्ट्रक्चर को फिर से बनाए बिना विफलताओं का पता लगा सकते हैं, लागत की निगरानी कर सकते हैं और प्रदर्शन को अनुकूलित (optimize) कर सकते हैं।