तीन कोडबेसच्या (codebases) पुनरावलोकनावरून असे दिसून येते की, केवळ OpenTelemetry (OTel) इंस्टॉल केल्याने AI-assisted coding agents साठी आवश्यक असलेला 'फीडबॅक लूप' (feedback loop) पूर्ण होत नाही. जर हा लूप कार्यरत नसेल, तर टेलिमेट्री (telemetry) एजंटला काय बदल करायचे हे ठरवण्यास मदत करू शकत नाही आणि डेव्हलपर्स अशा टूलवर वेळ वाया घालवतात जे मॉडेलशी कधीच संवाद साधत नाही.
“observability-first” मानसिकता अपयशी का ठरते
अनेक टीम्स observability कडे केवळ एक 'चेकबॉक्स' म्हणून पाहतात: एक tracing library वापरा, डॅशबोर्ड सक्षम करा आणि काम संपले असे समजा. पण वास्तव हे तीन टप्प्यांच्या शिडीसारखे आहे:
- एक observability mechanism अस्तित्वात असणे.
- सिस्टम प्रत्यक्षात telemetry तयार करणे.
- AI agent त्या telemetry चा वापर निर्णय घेण्यासाठी करू शकणे.
बहुतेक प्रकल्प टप्पा १ वरच अडकून पडतात. जर ॲप्लिकेशनने कधीही middleware ला कॉल केला नाही, तर उत्तम प्रकारे instrument केलेले middleware देखील निरुपयोगी ठरते आणि शून्य डेटा तयार होतो. सोर्स कोड स्कॅन करणारा AI agent ट्रेसिंग कोड पाहून सिस्टम 'observable' आहे असे गृहीत धरतो, परंतु प्रत्यक्षात रनटाइममध्ये त्याला काहीही माहिती मिळत नाही. "टूल असणे" आणि "लूप असणे" यातील हीच तफावत सर्व प्रयत्नांना निष्फळ ठरवते.
वापरण्यायोग्य डेटासाठी सहा अटी
रॉ ट्रेसेसचे (raw traces) AI coding agent साठी उपयुक्त इनपुटमध्ये रूपांतर करण्यासाठी, telemetry ने खालील सहा व्यावहारिक अटी पूर्ण करणे आवश्यक आहे:
- Standardization (प्रमाणकीकरण). सुसंगत attribute नावे आणि प्रकार वापरा जेणेकरून एजंट कोणत्याही विशेष मॅपिंगशिवाय डेटा पार्स (parse) करू शकेल.
- Propagation (प्रसार). सर्व सर्व्हिसेस आणि लँग्वेज बाउंड्रीजमध्ये एकच trace identifier वापरा, ज्यामुळे एजंटला एंड-टू-एंड एक्झिक्यूशन पुन्हा तयार करता येईल.
- Discoverability (शोधक्षमता). कोड-लेव्हल हुक्स किंवा साध्या CLI कमांड्सद्वारे डेटा उपलब्ध करून द्या, जेणेकरून मॉडेलला मॅन्युअली शोधण्याशिवाय तो शोधता येईल.
- Controllability (नियंत्रणक्षमता). एजंटला वेळ किंवा निकालांच्या संख्येनुसार क्वेरीज मर्यादित करण्याची परवानगी द्या, जेणेकरून तो अनावश्यक spans मुळे गोंधळून जाणार नाही.
- Accessibility (प्रवेशयोग्यता). एजंट ज्या सेशनमध्ये चालतो, त्याच सेशनमध्ये डेटा वाचनीय ठेवा; शक्यतो स्थानिक फाईल किंवा stdout स्ट्रीममधून.
- Comparability (तुलनाक्षमता). समान परिस्थितीत “before” आणि “after” स्नॅपशॉट्स मिळवण्याची पद्धत उपलब्ध करून द्या, जेणेकरून एजंट बदलाचा परिणाम मोजू शकेल.
जेव्हा यापैकी कोणताही आधारस्तंभ गहाळ असतो, तेव्हा फीडबॅक लूप तुटतो आणि AI agent केवळ अंदाज लावू लागतो.
डेव्हलपमेंटसाठी क्लाउडपेक्षा लोकल पाइपलाइन्स अधिक चांगल्या
प्रोडक्शन एन्व्हायरनमेंटमध्ये क्लाउड-आधारित telemetry collectors, aggregation services आणि डॅशबोर्ड्सवर अवलंबून राहणे आवश्यक असते. मोठ्या प्रमाणावर मॉनिटरिंगसाठी या पाइपलाइन्स महत्त्वाच्या आहेत, परंतु यामुळे मिनिटांच्या स्वरूपात विलंब (latency) निर्माण होतो. डेटासाठी मिनिटांची वाट पाहणारा AI agent अशा डेव्हलपमेंट लूपमध्ये सहभागी होऊ शकत नाही, ज्याला सेकंदात निर्णय घ्यावे लागतात.
याचा व्यावहारिक पर्याय म्हणजे local telemetry pipeline:
- telemetry स्थानिक फाईल्स किंवा stdout मध्ये लिहा. OTel अशा exporters ला सपोर्ट करते जे JSON किंवा plain-text spans थेट डेव्हलपरच्या वर्कस्पेसमध्ये डंप करू शकतात.
- साध्या टूल्सद्वारे डेटा उपलब्ध करून द्या. एक मिनिमल HTTP server, कमांड-लाइन क्वेरी इंटरफेस किंवा हलके SQL wrapper एजंटला गरजेनुसार ट्रेसेस पुरवू शकतात.
- एजंटला रॉ आउटपुट वाचू द्या. JSON किंवा Markdown स्वरूपात असलेला डेटा लँग्वेज मॉडेल्ससाठी त्याच एडिट सेशनमध्ये पार्स करणे आणि तुलना करणे सोपे असते.
मोठ्या प्रमाणावर auto-instrumentation करणे म्हणजे केवळ गोंधळ (noise) वाढवणे होय. त्याऐवजी, एखादा महत्त्वाचा एक्झिक्यूशन पाथ निवडा—जसे की request handling routine किंवा build step—आणि त्याचे एंड-टू-एंड instrumentation करा. ही साखळी पूर्ण करा: Generate → Propagate → Store → Query → Compare. एकदा का तो लूप व्यवस्थित काम करू लागला की, तो टप्प्याटप्प्याने वाढवा.
टीम्सनी पुढे काय करावे
- सर्वात मौल्यवान फ्लो (flow) ओळखा. असा कोड निवडा जिथे बदलामुळे परफॉर्मन्स किंवा अचूकतेवर मोजता येण्याजोगा परिणाम होईल.
- त्या फ्लोचे OTel ने instrument करा. spans तयार करण्यासाठी, प्रमाणित attributes जोडण्यासाठी आणि trace context प्रसारित करण्यासाठी लँग्वेज-विशिष्ट API वापरा.
- स्थानिक पातळीवर एक्सपोर्ट करा. प्रोजेक्ट डिरेक्टरीमधील फाईलमध्ये JSON lines लिहिण्यासाठी किंवा कन्सोलवर प्रिंट करण्यासाठी exporter कॉन्फिगर करा.
- क्वेरी इंटरफेस उपलब्ध करून द्या. trace ID आणि वेळेच्या विंडोनुसार फाईल फिल्टर करणारा एक छोटा स्क्रिप्ट एजंटला योग्य डेटा मिळवण्यासाठी पुरेसा आहे.
- डेटा AI agent ला द्या. मॉडेलला “before” ट्रेस देऊन बदलासाठी विचारा, त्यानंतर अपडेटेड कोड चालवा आणि तुलनेसाठी “after” ट्रेस गोळा करा.
- पुनरावृत्ती (Iterate) करा. प्रत्येक यशस्वी लूप सहा अटींची पडताळणी करतो आणि observable surface area वाढवतो.
Takeaway
OpenTelemetry तुमच्या कोडला ट्रेसिंगसाठी एक समान भाषा प्रदान करते, परंतु ही भाषा तेव्हाच उपयुक्त ठरते जेव्हा डेटा सहा ठोस अटी पूर्ण करतो आणि एका जलद फीडबॅक लूपमध्ये स्थानिक पातळीवर उपलब्ध असतो. लहान सुरुवात करा, एका सिंगल फ्लोचे इन्स्ट्रुमेंटेशन करा, फाईलमध्ये एक्सपोर्ट करा आणि AI एजंटला त्याच ठिकाणी ट्रेसेस वाचू आणि त्यांची तुलना करू द्या. "माझ्याकडे ऑब्झर्व्हेबिलिटी आहे" कडून "माझा AI असिस्टंट खरोखरच माझा कोड सुधारू शकतो" या स्थितीकडे जाण्याचा हा एक व्यावहारिक मार्ग आहे.