Microsoft-ன் Foundry குழு தனது agent framework-இல் OpenTelemetry அடிப்படையிலான tracing-ஐச் சேர்த்துள்ளது, இது பல்வேறு வகையான LLM-ஆல் இயங்கும் agents இடையிலான end-to-end செயல்பாட்டைப் பார்ப்பதற்கான வழியை டெவலப்பர்களுக்கு வழங்குகிறது.

ஏன் மல்டி-ஏஜென்ட் (multi-agent) அமைப்புகளுக்கு லாக் கோப்புகளைத் (log files) தாண்டி கூடுதல் வசதிகள் தேவை?

ஒரு வழக்கமான AI-ஆல் இயக்கப்படும் incident-response பயிற்சியில், ஒரு commander agent பல specialist agents-களை ஒருங்கிணைக்கிறது: ஒன்று logs-களைப் பகுப்பாய்வு செய்கிறது, மற்றொன்று metric anomalies-களைக் கண்டறிகிறது, மூன்றாவது அறிகுறிகளை runbooks-உடன் ஒப்பிடுகிறது, மேலும் ஒரு router ஒவ்வொரு துணைப் பணிக்கும் (sub-task) சிறந்த language model-ஐத் தேர்ந்தெடுக்கிறது. ஒவ்வொரு specialist agent-உம் ஒரு மாறுபட்ட மாடலை—உதாரணமாக, ஒரு “gpt-5-mini” variant-ஐ—அழைக்கலாம் மற்றும் அதன் சொந்த கருவிகளைப் (tools) பயன்படுத்தலாம். ஏதேனும் தவறு நடக்கும்போது, பொறியாளர்கள் ஒவ்வொரு அங்கமும் என்ன செய்தது என்பதைக் காட்டும் தனித்தனி logs-களை மட்டுமே பார்க்க முடிகிறது, ஆனால் அந்தப் பாகங்கள் எவ்வாறு ஒன்றிணைந்து செயல்படுகின்றன என்பதற்கான முழுமையான பார்வையை அவர்களால் பெற முடிவதில்லை.

ஒரு ஒருங்கிணைந்த trace இல்லையென்றால், agents இடையிலான தகவல் பரிமாற்றத்தில் (hand-off) மூலக் காரணம் (root cause) மறைந்துவிடும். commander ஒரு கோரிக்கையை அனுப்பலாம், அதை log-reader சரியாகக் கையாளலாம், ஆனால் metric specialist தரவைத் தவறாகப் புரிந்துகொண்டு தவறான runbook-ஐப் பரிந்துரைக்கலாம். அந்தச் சங்கிலித் தொடரை (chain) கைமுறையாகத் சரிசெய்வது (debugging) அதிக நேரமெடுப்பதோடு பிழைகளுக்கும் வழிவகுக்கும்.

OpenTelemetry எவ்வாறு பணிப்பாய்வை (workflow) ஒன்றிணைக்கிறது

OpenTelemetry இரண்டு முக்கியக் கருத்துக்களை வரையறுக்கிறது: traces மற்றும் spans. ஒரு trace என்பது ஒரு கோரிக்கை (request) உள்ளே நுழைந்தது முதல் இறுதிப் பதில் (final response) வரும் வரை அதைப் பின்தொடரும் ஒரு தனித்துவமான அடையாளமாகும் (unique identifier). ஒரு span என்பது அந்த trace-க்குள் நடக்கும் ஒரு ஒற்றைச் செயல்பாட்டை—உதாரணமாக, ஒரு language model-க்கான அழைப்பு அல்லது ஒரு tool invocation—பதிவு செய்கிறது.

ஒரு agent ஒரு கோரிக்கையைப் பெறும்போது, அது அந்த கோரிக்கையின் metadata-விலிருந்து வரும் Trace ID-யைப் பெற்று, அதே ID-யைப் பெறும் ஒரு child span-ஐ உருவாக்குகிறது. அந்த child span அதன் தொடக்க நேரம், கால அளவு (duration), பண்புகள் (attributes - model name, tool used) மற்றும் ஏதேனும் பிழைகளை (errors) பதிவு செய்கிறது. இந்தச் செயல்முறை ஒவ்வொரு downstream agent-க்கும் மீண்டும் மீண்டும் நடப்பதன் மூலம், ஒட்டுமொத்தப் பணியின் தர்க்கரீதியான ஓட்டத்தைப் (logical flow) பிரதிபலிக்கும் ஒரு மரக் கட்டமைப்பை (tree) உருவாக்குகிறது.

OpenTelemetry Baggage என்பதையும் ஆதரிக்கிறது, இது தனிப்பயனாக்கப்பட்ட key-value ஜோடிகளுக்கான (custom key-value pairs) ஒரு இலகுவான கடத்தியாகும் (lightweight carrier). Trace-இன் தொடக்கத்தில் baggage-இல் ஒரு “drill-id” அல்லது பிற வணிகச் சூழலை (business context) இணைப்பதன் மூலம், ஒவ்வொரு downstream span-உம் தானாகவே அந்த அடையாளத்தைப் பெறுகிறது. பின்னர் ஒரு span processor அந்த baggage-ஐ சாதாரண attributes-ஆக மாற்றுகிறது, இது ஒரு குறிப்பிட்ட incident drill-க்குச் சொந்தமான அனைத்து spans-களையும் எளிதாகக் கண்டறிய (query) உதவுகிறது.

புதிய tracing surface எப்படி இருக்கும்

Instrumentation தயாராக இருக்கும்போது, Azure Monitor (அல்லது OpenTelemetry-க்கு இணக்கமான எந்தவொரு backend-உம்) ஒரு காட்சி படிநிலையை (visual hierarchy) வழங்குகிறது:

  • Agent name / ID – எந்தக் கூறு (component) செயல்பாட்டைச் செய்தது என்பதைக் காட்டுகிறது.
  • Tool usage – எந்த வெளிப்புறச் சேவை அல்லது function அழைக்கப்பட்டது என்பதைப் பதிவு செய்கிறது.
  • Model version – பயன்படுத்தப்பட்ட துல்லியமான LLM-ஐப் பதிவு செய்கிறது, இது ஒரு மாடல் மேம்படுத்தலுக்குப் பிறகு ஏற்படும் பின்னடைவுகளைக் (regressions) கண்காணிக்கப் பயனுள்ளதாக இருக்கும்.
  • Token consumption – மாடலுக்கு எத்தனை tokens அனுப்பப்பட்டன மற்றும் மாடலில் இருந்து எத்தனை பெறப்பட்டன என்பதைப் பதிவு செய்கிறது, இது குழுக்கள் செலவை நிர்வகிக்க உதவுகிறது.
  • Latency / duration – மாடல் inference அல்லது tool I/O ஆகியவற்றில் எங்குத் தடைகள் (bottlenecks) ஏற்படுகின்றன என்பதைக் காட்டுகிறது.

incident-drill உதாரணத்தில், commander-இன் root span ஒவ்வொரு specialist-க்கும் child spans-களை உருவாக்குகிறது, மேலும் ஒவ்வொரு specialist-உம் அதன் model calls-களுக்காக மேலும் child spans-களை உருவாக்குகிறது. ஏதேனும் ஒரு node-ஐக் கிளிக் செய்வதன் மூலம் முழுமையான attribute தொகுப்பைக் காணலாம், இதனால் ஒரு பொறியாளர் ஒவ்வொரு செயல்பாட்டின் விவரங்களையும் உடனடியாகப் பார்க்க முடியும்.

AI-மையச் செயல்பாடுகளுக்கான முக்கியத்துவம் (The stakes)

  • Root-cause analysis-இன் வேகம் – குழுக்கள் ஒரு தோல்வியைத் துல்லியமாகப் பிழையைத் தந்த span-க்குத் தேடிச் சென்று கண்டறியலாம், இது சிக்கலைத் தீர்க்க எடுக்கும் சராசரி நேரத்தைக் (mean time to resolution) குறைக்கிறது.
  • செலவுத் தெரிவுத்திறன் (Cost visibility) – Token எண்ணிக்கையானது latency-இன் அருகிலேயே இருப்பதால், கிளவுட் கட்டணங்கள் (cloud bills) அதிகரிப்பதற்கு முன்பே நிதித் துறையினர் அதீதப் பயன்பாட்டைக் கண்டறிய முடிகிறது.
  • செயல்திறன் மேம்பாடு (Performance tuning) – ஏஜென்ட்கள் இடையிலான அதிக latency கொண்ட spans, எங்கு caching, model selection அல்லது tool redesign மூலம் செயல்திறனை (throughput) அதிகரிக்கலாம் என்பதைக் காட்டுகின்றன.

அடுத்து என்ன எதிர்பார்க்கலாம்

LangChain, OpenAI SDK அல்லது பிற orchestration layers-இல் கட்டமைக்கப்பட்ட திட்டங்கள் GenAI-க்கான அதே semantic conventions-களைப் பின்பற்றலாம், இது cloud providers மற்றும் on-premise deployments ஆகியவற்றில் பாயும் traces-களுக்கு வழிவகுக்கும்.

நிறுவனங்கள் தங்கள் agents-இல் OpenTelemetry SDK-ஐச் செயல்படுத்தி, தரவை Azure Monitor அல்லது ஒரு open-source collector-க்கு அனுப்பினால் போதுமானது.

சுருக்கம் (Takeaway)

சிதறிக்கிடக்கும் logs-களை ஒரு தெளிவான கதையாக மாற்றும் அந்தத் தேவையான பிணைப்பை (glue) OpenTelemetry மல்டி-ஏஜென்ட் AI அமைப்புகளுக்கு வழங்குகிறது. பல்வேறு வகையான LLMs, routers மற்றும் tool calls ஆகியவற்றில் ஒரு ஒற்றை Trace ID-யைப் பரப்புவதன் மூலம், டெவலப்பர்கள் புதிய tracing infrastructure-ஐ உருவாக்கத் தேவையில்லாமல், தோல்விகளைக் கண்டறியவும், செலவுகளைக் கண்காணிக்கவும் மற்றும் செயல்திறனை மேம்படுத்தவும் முடியும்.