Microsoft च्या Foundry टीमने त्यांच्या agent framework मध्ये OpenTelemetry-आधारित tracing जोडले आहे, ज्यामुळे डेव्हलपर्सना विविध (heterogeneous) LLM-आधारित agents मधील एंड-टू-एंड एक्झिक्यूशन पाहण्याचा मार्ग उपलब्ध झाला आहे.

मल्टी-एजंट सिस्टम्सना केवळ लॉग फाइल्सपेक्षा अधिक कशाची गरज आहे

एका सामान्य AI-चालित इन्सिडेंट-रिस्पॉन्स ड्रिलमध्ये (incident-response drill) एका 'कमांडर एजंट'चा वापर केला जातो जो अनेक 'स्पेशालिस्ट एजंट्स'चे समन्वय साधतो: एक लॉग्सचे विश्लेषण (parse) करतो, दुसरा मेट्रिकमधील विसंगती (anomalies) शोधतो, तिसरा लक्षणांची (symptoms) रनबुक्सशी (runbooks) तुलना करतो आणि एक राउटर प्रत्येक उप-कार्यासाठी (sub-task) सर्वोत्तम लँग्वेज मॉडेल निवडतो. प्रत्येक स्पेशालिस्ट वेगळे मॉडेल—उदा. “gpt-5-mini” व्हेरिएंट—वापरू शकतो आणि स्वतःची टूल्स वापरू शकतो. जेव्हा काही चुकते, तेव्हा इंजिनिअर्सना केवळ विलग (isolated) लॉग्स दिसतात जे प्रत्येक घटक काय करत होता हे दर्शवतात, परंतु सर्व भाग एकमेकांशी कसे जोडलेले आहेत याचा कोणताही समग्र दृष्टिकोन मिळत नाही.

युनिफाइड ट्रेस (unified trace) शिवाय, मूळ कारण (root cause) एजंट्समधील डेटा हस्तांतरणामध्ये (hand-off) लपलेले असते. कमांडरने पाठवलेली विनंती लॉग-रीडरने योग्यरित्या हाताळली असली तरी, मेट्रिक स्पेशालिस्ट डेटाचा चुकीचा अर्थ लावू शकतो आणि चुकीचा रनबुक सुचवू शकतो. अशा साखळीचे मॅन्युअली डीबगिंग करणे वेळखाऊ असते आणि त्यात चुका होण्याची शक्यता असते.

OpenTelemetry वर्कफ्लोला एकत्र कसे जोडते

OpenTelemetry दोन मुख्य संकल्पना परिभाषित करते: traces आणि spans. 'Trace' हा एक युनिक आयडेंटिफायर आहे जो विनंतीच्या (request) सुरुवातीपासून अंतिम प्रतिसादापर्यंत (response) त्याचा मागोवा घेतो. 'Span' हा त्या ट्रेसमधील एका विशिष्ट ऑपरेशनची नोंद करतो—जसे की लँग्वेज मॉडेलला केलेली कॉल किंवा टूल इनव्होकेशन (tool invocation).

जेव्हा एखादा एजंट विनंती प्राप्त करतो, तेव्हा तो विनंतीच्या मेटाडेटा (metadata) मधून येणारा Trace ID घेतो आणि त्याच ID चा वारसा लाभलेला एक 'child span' तयार करतो. हा child span त्याचा सुरुवातीचा वेळ, कालावधी, ॲट्रिब्युट्स (मॉडेलचे नाव, वापरलेले टूल) आणि कोणत्याही त्रुटींची (errors) नोंद करतो. ही प्रक्रिया प्रत्येक डाउनस्ट्रीम (downstream) एजंटसाठी पुन्हा पुन्हा घडते, ज्यामुळे संपूर्ण कार्याचा लॉजिकल फ्लो दर्शवणारा एक 'ट्री' (tree) तयार होतो.

OpenTelemetry Baggage ला देखील सपोर्ट करते, जे कस्टम की-व्हॅल्यू जोड्यांसाठी (key-value pairs) एक हलका वाहक (lightweight carrier) आहे. ट्रेसच्या सुरुवातीलाच बॅगेजमध्ये “drill-id” किंवा इतर बिझनेस कॉन्टेक्स्ट जोडून, प्रत्येक डाउनस्ट्रीम स्पॅन आपोआप तो आयडेंटिफायर प्राप्त करतो. त्यानंतर, एक 'span processor' या बॅगेजला नियमित ॲट्रिब्युट्समध्ये रूपांतरित करतो, ज्यामुळे एखाद्या विशिष्ट इन्सिडेंट ड्रिलशी संबंधित सर्व स्पॅन्स शोधणे (query करणे) सोपे होते.

नवीन ट्रेसिंग सरफेस कसा दिसतो

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

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

इन्सिडेंट-ड्रिलच्या उदाहरणात, कमांडरचा 'root span' प्रत्येक स्पेशालिस्टसाठी 'child spans' तयार करतो आणि प्रत्येक स्पेशालिस्ट त्याच्या मॉडेल कॉल्ससाठी आणखी 'children' तयार करतो. कोणत्याही नोडवर क्लिक केल्यास संपूर्ण ॲट्रिब्युट सेट दिसतो, ज्यामुळे इंजिनिअरला प्रत्येक ऑपरेशनचा तपशील त्वरित समजतो.

AI-केंद्रित ऑपरेशन्ससाठीचे महत्त्व

  • मूळ-कारण विश्लेषणाचा वेग (Speed of root-cause analysis) – टीम्स त्रुटी नेमक्या कोणत्या स्पॅनमध्ये आली आहे याचा मागोवा घेऊ शकतात, ज्यामुळे 'मीन टाइम टू रिझोल्यूशन' (mean time to resolution) कमी होतो.
  • खर्चाची दृश्यता (Cost visibility) – टोकन काउंट लॅटन्सीसोबत (latency) दिसल्यामुळे, क्लाउड बिले वाढण्यापूर्वीच फायनान्स टीमला वाढत्या वापराची कल्पना येते.
  • परफॉर्मन्स ट्यूनिंग (Performance tuning) – एजंट्समधील हाय-लॅटन्सी स्पॅन्समुळे हे समजते की कॅशिंग (caching), मॉडेल निवड किंवा टूल रिडिझाइनद्वारे थ्रूपुट (throughput) कसा वाढवता येईल.

पुढे काय पाहावे

LangChain, OpenAI SDK किंवा इतर ऑर्केस्ट्रेशन लेयर्सवर (orchestration layers) आधारित प्रोजेक्ट्स GenAI साठी समान सिमेंटिक कन्व्हेन्शन्स (semantic conventions) स्वीकारू शकतात, ज्यामुळे क्लाउड प्रोव्हायडर्स आणि ऑन-प्रिमाइस (on-premise) डिप्लॉयमेंट्समध्ये प्रवाहित होणाऱ्या ट्रेससाठी मार्ग मोकळा होईल.

संस्था फक्त त्यांच्या एजंट्समध्ये OpenTelemetry SDK सक्षम करू शकतात आणि डेटा Azure Monitor किंवा ओपन-सोर्स कलेक्टरला पाठवू शकतात.

निष्कर्ष

OpenTelemetry मल्टी-एजेंट AI सिस्टम्सना तो महत्त्वाचा दुवा (glue) प्रदान करते जो विखुरलेल्या लॉग्सचे रूपांतर एका सुसंगत कथनात (coherent narrative) करतो. विविध (heterogeneous) LLMs, राउटर आणि टूल कॉल्समध्ये एकच Trace ID प्रसारित करून, डेव्हलपर्स ट्रेसिंग इन्फ्रास्ट्रक्चर पुन्हा तयार न करता त्रुटी शोधू शकतात, खर्चावर लक्ष ठेवू शकतात आणि परफॉर्मन्स ऑप्टिमाइझ करू शकतात.