മൂന്ന് കോഡ്ബേസുകളുടെ (codebases) അവലോകനം സൂചിപ്പിക്കുന്നത് വെറുതെ OpenTelemetry (OTel) ഇൻസ്റ്റാൾ ചെയ്യുന്നത് കൊണ്ട് മാത്രം AI-അസിസ്റ്റഡ് കോഡിംഗ് ഏജന്റുകൾക്കായുള്ള ഫീഡ്ബാക്ക് ലൂപ്പ് (feedback loop) പൂർണ്ണമാകില്ല എന്നാണ്. ഒരു പ്രവർത്തനക്ഷമമായ ലൂപ്പ് ഇല്ലാതെ, ടെലിമെട്രിക്ക് (telemetry) ഏജന്റിന് എന്ത് മാറ്റം വരുത്തണമെന്ന് തീരുമാനിക്കാൻ സഹായിക്കാനാവില്ല, കൂടാതെ മോഡലുമായി ഒരിക്കലും സംവദിക്കാത്ത ഒരു ടൂൾ ചേർക്കുന്നതിലൂടെ ഡെവലപ്പർമാരുടെ സമയം പാഴാകുകയും ചെയ്യുന്നു.
എന്തുകൊണ്ടാണ് “observability-first” ചിന്താഗതി പരാജയപ്പെടുന്നത്
പല ടീമുകളും observability-യെ വെറുമൊരു ചെക്ക്ബോക്സ് ആയിട്ടാണ് കാണുന്നത്: ഒരു ട്രേസിംഗ് ലൈബ്രറി (tracing library) ചേർക്കുക, ഒരു ഡാഷ്ബോർഡ് (dashboard) പ്രവർത്തനക്ഷമമാക്കുക, എന്നിട്ട് അത് കഴിഞ്ഞു എന്ന് കരുതുക. എന്നാൽ യഥാർത്ഥത്തിൽ ഇത് മൂന്ന് ഘട്ടങ്ങളുള്ള ഒരു ഏണി പോലെയാണ്:
- ഒരു observability മെക്കാനിസം നിലവിലുണ്ട്.
- സിസ്റ്റം യഥാർത്ഥത്തിൽ telemetry ഉൽപ്പാദിപ്പിക്കുന്നു.
- ഒരു AI ഏജന്റിന് ആ telemetry ഉപയോഗിച്ച് തീരുമാനങ്ങൾ എടുക്കാൻ സാധിക്കുന്നു.
മിക്ക പ്രോജക്റ്റുകളും ഒന്നാം ഘട്ടത്തിൽ തന്നെ തടസ്സപ്പെടുന്നു. ഒരു ആപ്ലിക്കേഷൻ ഒരിക്കലും ഉപയോഗിക്കാത്ത പക്ഷം, കൃത്യമായി ഇൻസ്ട്രുമെന്റ് ചെയ്ത (instrumented) ഒരു മിഡിൽവെയർ (middleware) വെറുതെ ഇരിക്കുകയും സീറോ ഡാറ്റ മാത്രം നൽകുകയും ചെയ്യുന്നു. സോഴ്സ് കോഡ് സ്കാൻ ചെയ്യുന്ന ഒരു AI ഏജന്റ് ട്രേസിംഗ് കോഡ് കാണുമ്പോൾ സിസ്റ്റം observable ആണെന്ന് കരുതുന്നു, എന്നാൽ റൺടൈമിൽ (runtime) ഡാറ്റ ഇല്ലാത്ത അവസ്ഥയാണ് നേരിടുന്നത്. “ഒരു ടൂൾ ഉണ്ടാവുക” എന്നതും “ഒരു ലൂപ്പ് ഉണ്ടാവുക” എന്നതും തമ്മിലുള്ള വ്യത്യാസമാണ് പ്രയത്നങ്ങളെ പരാജയപ്പെടുത്തുന്നത്.
ഉപയോഗപ്രദമായ ഡാറ്റയ്ക്കായുള്ള ആറ് നിബന്ധനകൾ
റോ ഡാറ്റാ ട്രേസുകളെ (raw traces) ഒരു AI കോഡിംഗ് ഏജന്റിന് ഉപയോഗപ്രദമായ ഇൻപുട്ട് ആക്കി മാറ്റാൻ, telemetry താഴെ പറയുന്ന ആറ് പ്രായോഗിക നിബന്ധനകൾ പാലിക്കേണ്ടതുണ്ട്:
- Standardization. ഏജന്റിന് പ്രത്യേക മാപ്പിംഗ് ഇല്ലാതെ തന്നെ ഡാറ്റ വിശകലനം ചെയ്യാൻ കഴിയുന്ന രീതിയിൽ ഒരേപോലെയുള്ള അറ്റ്രിബ്യൂട്ട് പേരുകളും (attribute names) തരങ്ങളും ഉപയോഗിക്കുക.
- Propagation. എല്ലാ സർവീസുകളിലൂടെയും ഭാഷാപരമായ അതിർവരമ്പുകളിലൂടെയും (language boundaries) ഒരൊറ്റ ട്രേസ് ഐഡന്റിഫയർ (trace identifier) കൈമാറുക, ഇത് ഏജന്റിന് ഒരു എൻഡ്-ടു-എൻഡ് എക്സിക്യൂഷൻ (end-to-end execution) പുനർനിർമ്മിക്കാൻ സഹായിക്കുന്നു.
- Discoverability. കോഡ് ലെവൽ ഹുക്കുകളിലൂടെയോ (code-level hooks) ലളിതമായ CLI കമാൻഡുകളിലൂടെയോ ഡാറ്റ ലഭ്യമാക്കുക, അങ്ങനെ മോഡലിന് നേരിട്ട് ഡാറ്റ കണ്ടെത്താൻ സാധിക്കണം.
- Controllability. സമയപരിധിയിലോ റിസൾട്ട് എണ്ണത്തിലോ ക്വറികൾ പരിമിതപ്പെടുത്താൻ ഏജന്റിനെ അനുവദിക്കുക, ഇത് അനാവശ്യമായ സ്പാനുകൾ (spans) കാരണം ഏജന്റ് തളരാതിരിക്കാൻ സഹായിക്കുന്നു.
- Accessibility. ഏജന്റ് പ്രവർത്തിക്കുന്ന അതേ സെഷനിൽ തന്നെ ഡാറ്റ വായിക്കാൻ കഴിയുന്ന രീതിയിൽ സൂക്ഷിക്കുക, ഒരു ലോക്കൽ ഫയൽ വഴിയോ stdout സ്ട്രീം വഴിയോ ഇത് സാധ്യമാണ്.
- Comparability. ഒരു മാറ്റത്തിന്റെ ഫലം അളക്കാൻ സാധിക്കുന്നതിനായി, ഒരേ സാഹചര്യങ്ങളിൽ തന്നെ “മുൻപത്തെ” (before), “ശേഷമുള്ള” (after) സ്നാപ്പ്ഷോട്ടുകൾ ലഭ്യമാക്കുക.
ഈ തൂണുകളിൽ ഏതെങ്കിലും ഒന്ന് ഇല്ലെങ്കിൽ, ഫീഡ്ബാക്ക് ലൂപ്പ് തകരാറിലാകുകയും AI ഏജന്റ് ഊഹങ്ങൾ മാത്രം അടിസ്ഥാനമാക്കി പ്രവർത്തിക്കുകയും ചെയ്യുന്നു.
ഡെവലപ്മെന്റിന് ക്ലൗഡിനേക്കാൾ മികച്ചത് ലോക്കൽ പൈപ്പ്ലൈനുകളാണ്
പ്രൊഡക്ഷൻ എൻവയോൺമെന്റുകൾ ക്ലൗഡ് അധിഷ്ഠിത ടെലിമെട്രി കളക്ടറുകളെയും (telemetry collectors), അഗ്രഗേഷൻ സർവീസുകളെയും (aggregation services), ഡാഷ്ബോർഡുകളെയും ആശ്രയിക്കുന്നു. വലിയ തോതിലുള്ള മോണിറ്ററിംഗിന് ഈ പൈപ്പ്ലൈനുകൾ അത്യാവശ്യമാണ്, എന്നാൽ അവ മിനിറ്റുകൾ നീണ്ടുനിൽക്കുന്ന ലേറ്റൻസി (latency) ഉണ്ടാക്കുന്നു. സെക്കൻഡുകൾക്കുള്ളിൽ തീരുമാനങ്ങൾ എടുക്കേണ്ട ഒരു ഡെവലപ്മെന്റ് ലൂപ്പിൽ, ഡാറ്റയ്ക്കായി മിനിറ്റുകൾ കാത്തുനിൽക്കുന്ന ഒരു AI ഏജന്റിന് പങ്കുചേരാൻ കഴിയില്ല.
ഇതിന് പ്രായോഗികമായ ഒരു ബദൽ ലോക്കൽ ടെലിമെട്രി പൈപ്പ്ലൈൻ (local telemetry pipeline) ആണ്:
- ടെലിമെട്രി ലോക്കൽ ഫയലുകളിലേക്കോ stdout ലേക്കോ എഴുതുക. ഡെവലപ്പറുടെ വർക്ക്സ്പേസിലേക്ക് നേരിട്ട് JSON അല്ലെങ്കിൽ പ്ലെയിൻ ടെക്സ്റ്റ് സ്പാനുകൾ (plain-text spans) ഡമ്പ് ചെയ്യുന്ന എക്സ്പോർട്ടറുകളെ (exporters) OTel പിന്തുണയ്ക്കുന്നു.
- ലളിതമായ ടൂളുകൾ വഴി ഡാറ്റ ലഭ്യമാക്കുക. ഒരു മിനിമൽ HTTP സെർവർ, കമാൻഡ്-ലൈൻ ക്വറി ഇന്റർഫേസ്, അല്ലെങ്കിൽ ഒരു ലൈറ്റ് വെയ്റ്റ് SQL റാപ്പർ എന്നിവ വഴി ആവശ്യാനുസരണം ട്രേസുകൾ ഏജന്റിന് നൽകാം.
- റോ ഔട്ട്പുട്ട് ഏജന്റിനെ വായിക്കാൻ അനുവദിക്കുക. JSON അല്ലെങ്കിൽ Markdown രൂപങ്ങൾ ലാംഗ്വേജ് മോഡലുകൾക്ക് ഒരേ എഡിറ്റ് സെഷനിൽ തന്നെ വിശകലനം ചെയ്യാനും താരതമ്യം ചെയ്യാനും എളുപ്പമാണ്.
വലിയ തോതിലുള്ള ഓട്ടോ-ഇൻസ്ട്രുമെന്റേഷൻ (auto-instrumentation) നടത്തുന്നത് വെറുതെ നോയിസ് (noise) മാത്രമേ കൂട്ടുകയുള്ളൂ. ഒരു റിക്വസ്റ്റ് ഹാൻഡ്ലിംഗ് റൂട്ടീനോ (request handling routine) ബിൽഡ് സ്റ്റെപ്പോ (build step) പോലുള്ള ഒരു നിർണ്ണായക എക്സിക്യൂഷൻ പാത്ത് (execution path) മാത്രം തിരഞ്ഞെടുത്ത് അത് എൻഡ്-ടു-എൻഡ് ഇൻസ്ട്രുമെന്റ് ചെയ്യുക. ഈ ശൃംഖല പൂർത്തിയാക്കുക: Generate → Propagate → Store → Query → Compare. ആ ലൂപ്പ് പ്രവർത്തിച്ചു തുടങ്ങിയാൽ, അത് ഘട്ടം ഘട്ടമായി വിപുലീകരിക്കുക.
ടീമുകൾ ഇനി എന്താണ് ചെയ്യേണ്ടത്
- ഏറ്റവും മൂല്യമുള്ള ഫ്ലോ (flow) കണ്ടെത്തുക. ഒരു മാറ്റം വരുത്തിയാൽ പെർഫോമൻസിലോ കൃത്യതയിലോ (correctness) അളക്കാവുന്ന മാറ്റമുണ്ടാകുന്ന കോഡ് ഭാഗം തിരഞ്ഞെടുക്കുക.
- ആ ഫ്ലോ OTel ഉപയോഗിച്ച് ഇൻസ്ട്രുമെന്റ് ചെയ്യുക. സ്പാനുകൾ (spans) നിർമ്മിക്കാനും, സ്റ്റാൻഡേർഡൈസ്ഡ് അറ്റ്രിബ്യൂട്ടുകൾ ചേർക്കാനും, ട്രേസ് കോൺടെക്സ്റ്റ് (trace context) പ്രൊപ്പഗേറ്റ് ചെയ്യാനും ലാംഗ്വേജ് സ്പെസിഫിക് API ഉപയോഗിക്കുക.
- ലോക്കലായി എക്സ്പോർട്ട് ചെയ്യുക. പ്രോജക്റ്റ് ഡയറക്ടറിയിലെ ഒരു ഫയലിലേക്ക് JSON ലൈനുകൾ എഴുതാനോ അല്ലെങ്കിൽ കൺസോളിൽ പ്രിന്റ് ചെയ്യാനോ എക്സ്പോർട്ടർ കോൺഫിഗർ ചെയ്യുക.
- **ഒരു ക്വറി ഇന്റർഫേസ്
OpenTelemetry നിങ്ങളുടെ കോഡിന് ട്രേസിംഗിനായി ഒരു പൊതുവായ ഭാഷ നൽകുന്നു, എന്നാൽ ഡാറ്റ ആറ് കൃത്യമായ നിബന്ധനകൾ പാലിക്കുകയും ഒരു കൃത്യമായ ഫീഡ്ബാക്ക് ലൂപ്പിലൂടെ പ്രാദേശികമായി ലഭ്യമാവുകയും ചെയ്യുമ്പോൾ മാത്രമേ ആ ഭാഷ പ്രയോജനപ്പെടുകയുള്ളൂ. ചെറുതായി തുടങ്ങുക, ഒരു ഫ്ലോ മാത്രം ഇൻസ്ട്രുമെന്റ് ചെയ്യുക, ഒരു ഫയലിലേക്ക് എക്സ്പോർട്ട് ചെയ്യുക, തുടർന്ന് AI ഏജന്റിനെ ട്രേസുകൾ നേരിട്ട് വായിക്കാനും താരതമ്യം ചെയ്യാനും അനുവദിക്കുക. “എനിക്ക് ഒബ്സർവബിലിറ്റി ഉണ്ട്” എന്ന അവസ്ഥയിൽ നിന്ന് “എന്റെ AI അസിസ്റ്റന്റിന് യഥാർത്ഥത്തിൽ എന്റെ കോഡ് മെച്ചപ്പെടുത്താൻ കഴിയും” എന്ന അവസ്ഥയിലേക്കുള്ള പ്രായോഗികമായ പാതയാണത്.