CloudWatch மூலம் AI ஏஜென்ட்களைக் கண்காணித்தல்

ஒவ்வொரு ஏஜென்ட் அழைப்பையும் (agent call) ஒரு தரவுத்தளத்தில் (database) பதிவு செய்வது கண்காணிப்பு அல்ல. அது வெறும் சேமிப்பு மட்டுமே.

உங்கள் சுருக்கமானி (summarizer) மெதுவாகச் செயல்படுகிறதா என்பதைப் பார்க்க நீங்கள் அதிகாலை 2:00 மணிக்கு SQL வினவல்களை (queries) இயக்க வேண்டியிருந்தால், நீங்கள் கண்காணிப்புத் திறனில் (observability) தோல்வியடைந்துவிட்டீர்கள் என்று அர்த்தம். உங்களுக்குத் தேவைத் தரவுத்தள வரிசைகள் (database rows) அல்ல, டேஷ்போர்டுகளும் (dashboards) எச்சரிக்கைகளும் (alarms) தான்.

தாமதத்தையோ (latency) அல்லது சிக்கலான குறியீடுகளையோ சேர்க்காமல் AI ஏஜென்ட்களைக் கண்காணிக்க இரண்டு வழிகளைக் கண்டறிந்தேன்.

1. தோல்வி முறைகளுக்கு (Failure Modes) Metric Filters-ஐப் பயன்படுத்தவும்

பட்ஜெட் வரம்புகள் (budget caps) அல்லது சேவைத் தணிக்கை (service throttling) போன்ற தோல்வி முறைகள் கண்ணுக்குத் தெரியாமல் இருக்கக்கூடாது. ஒரு API-ஐ அழைக்க புதிய குறியீட்டை எழுத வேண்டாம். அதற்குப் பதிலாக, உங்கள் தற்போதைய பதிவுகளைப் (logs) பயன்படுத்தவும்.

பட்ஜெட் வரம்பு எட்டப்படும்போது, உங்கள் குறியீடு ஒரு பிழையைப் (error) பதிவு செய்யும். அந்தப் பதிவுகளை ஸ்கேன் செய்ய நீங்கள் ஒரு CloudWatch Metric Filter-ஐ அமைக்கலாம். அந்தப் பேட்டர்ன் (pattern) பொருந்தினால், CloudWatch ஒரு மெட்ரிக்கை (metric) அதிகரிக்கும்.

இந்த முறை மலிவானது. இதற்கு கூடுதல் IAM அனுமதிகள் தேவையில்லை மற்றும் உங்கள் ஏஜென்ட்டிற்கு எந்தத் தாமதத்தையும் (latency) ஏற்படுத்தாது.

இவற்றிற்கு இதைப் பயன்படுத்தவும்:

  • மாதந்திரச் செலவு வரம்பு எட்டப்பட்டது (Monthly cost cap reached)
  • Bedrock throttling பிழைகள்
  • பொதுவான ஏஜென்ட் தோல்விகள்

2. செயல்திறன் தரவுகளுக்கு (Performance Data) EMF-ஐப் பயன்படுத்தவும்

நீங்கள் தாமதம் (latency), டோக்கன் பயன்பாடு (token usage) அல்லது ஏஜென்ட் வாரியான செலவைக் கண்காணிக்க விரும்பினால், Metric Filters மட்டும் போதாது. உங்களுக்குத் தேவையான பரிமாணங்கள் (dimensions) தேவை.

PutMetricData-வைப் பயன்படுத்த வேண்டாம். இது ஒரு ஒத்திசைவு நெட்வொர்க் அழைப்பு (synchronous network call). இது உங்கள் கோரிக்கையில் (request) 30ms முதல் 80ms வரை தாமதத்தைச் சேர்க்கும். CloudWatch-மே அதிக சுமையில் இருந்தால் இது தோல்வியடையவும் வாய்ப்புள்ளது.

அதற்குப் பதிலாக, Embedded Metric Format (EMF)-ஐப் பயன்படுத்தவும்.

நீங்கள் stdout-க்கு ஒரு வரியிலான JSON-ஐ எழுதினால் போதும். CloudWatch தானாகவே இவற்றை பரிமாணங்களுடன் கூடிய மெட்ரிக்குகளாகப் பிரித்தெடுக்கும்.

ஒரே ஒரு JSON வரியுடன், நீங்கள் பெறுவது:

  • மொத்த அழைப்புகள் (Total invocations)
  • பிழை விகிதங்கள் (Error rates)
  • தாமதம் (Latency - P95)
  • உள்ளீடு மற்றும் வெளியீடு டோக்கன்கள் (Input and output tokens)
  • மாடல் மற்றும் ஏஜென்ட் வாரியான செலவு

திறமையான கண்காணிப்புத் திறனுக்கான விதிகள் (The Rules of Efficient Observability)

  • ஒரு வரியை வெளியிடுங்கள், CloudWatch வேலையைச் செய்யட்டும்.
  • டெலிமெட்ரி (telemetry) உங்கள் ஏஜென்ட்டைப் பாதிக்க அனுமதிக்காதீர்கள். உங்கள் மெட்ரிக் அழைப்புகளை try-except பிளாக்குகளில் (blocks) வைக்கவும்.
  • தனித்தனி நிகழ்வுகளுக்குப் பதிலாக, திடீர் அதிகரிப்புகளுக்கு (bursts) எச்சரிக்கை (alarm) அமைக்கவும். ஒருமுறை தணிக்கை (throttle) ஏற்படுவது இயல்பானது. ஆனால் ஐந்து நிமிடங்களில் பத்து முறை தணிக்கை ஏற்படுவது ஒரு அசம்பாவிதம் (incident).
  • குறிப்பிட்ட ஏஜென்ட்களுக்குப் பரிமாணங்களைப் (dimensions) பயன்படுத்தவும், ஆனால் கணினி முழுவதையும் உள்ளடக்கிய தாமதத்திற்குத் தொகுப்புகளைப் (aggregates) பயன்படுத்தவும்.
  • பிழைகளை உரைச் சரங்களால் (text strings) அல்லாமல், குறியீட்டின் (code) மூலம் கண்டறியவும்.

பதிவுகள் (logs) மற்றும் EMF ஆகியவற்றைப் பயன்படுத்தி நீங்கள் $0 செலவில் ஒரு தொழில்முறை கண்காணிப்பு கட்டமைப்பை (monitoring stack) உருவாக்க முடியும்.

Source: https://dev.to/aws-builders/monitorear-agentes-de-ia-con-cloudwatch-45c4

Optional learning community: https://t.me/GyaanSetuAi