CloudWatch के साथ AI Agents की मॉनिटरिंग

हर एजेंट कॉल को डेटाबेस में लॉग करना मॉनिटरिंग नहीं है। यह केवल स्टोरेज है।

यदि आपको यह देखने के लिए रात के 2:00 बजे SQL क्वेरी चलानी पड़ती है कि आपका summarizer धीमा है या नहीं, तो आप observability में विफल रहे हैं। आपको डैशबोर्ड और अलार्म की आवश्यकता है, डेटाबेस रोज़ (rows) की नहीं।

मैंने बिना लेटेंसी (latency) या जटिल कोड जोड़े AI agents की मॉनिटरिंग करने के दो तरीके खोजे हैं।

1. Failure Modes के लिए Metric Filters का उपयोग करें

बजट कैप (budget caps) या सर्विस थ्रॉटलिंग (service throttling) जैसे failure modes अदृश्य नहीं होने चाहिए। किसी API को कॉल करने के लिए नया कोड न लिखें। इसके बजाय, अपने मौजूदा लॉग्स का उपयोग करें।

जब बजट कैप हिट होता है, तो आपका कोड एक एरर लॉग करता है। आप उन लॉग्स को स्कैन करने के लिए CloudWatch Metric Filter सेट कर सकते हैं। यदि पैटर्न मैच होता है, तो CloudWatch एक metric को बढ़ा देता है।

यह तरीका सस्ता है। इसके लिए किसी अतिरिक्त IAM permissions की आवश्यकता नहीं होती और यह आपके एजेंट में शून्य लेटेंसी जोड़ता है।

इसका उपयोग करें:

  • मासिक लागत सीमा (Monthly cost cap) तक पहुँचना
  • Bedrock throttling errors
  • सामान्य एजेंट विफलताएं (General agent failures)

2. Performance Data के लिए EMF का उपयोग करें

यदि आप लेटेंसी, टोकन उपयोग, या प्रति एजेंट लागत को ट्रैक करना चाहते हैं, तो Metric Filters पर्याप्त नहीं हैं। आपको dimensions की आवश्यकता है।

PutMetricData का उपयोग न करें। यह एक synchronous network call है। यह आपके अनुरोध (request) में 30ms से 80ms जोड़ देता है। यदि CloudWatch स्वयं लोड के अंतर्गत है, तो यह विफल भी हो सकता है।

इसके बजाय, Embedded Metric Format (EMF) का उपयोग करें।

आप stdout पर JSON की एक सिंगल लाइन लिखते हैं। CloudWatch स्वचालित रूप से इन्हें dimensions के साथ metrics के रूप में निकाल लेता है।

एक JSON लाइन के साथ, आपको मिलता है:

  • कुल इनवोकेशन्स (Total invocations)
  • एरर रेट्स (Error rates)
  • लेटेंसी (P95)
  • इनपुट और आउटपुट टोकन
  • प्रति मॉडल और प्रति एजेंट लागत

कुशल Observability के नियम

  • एक लाइन एमिट (emit) करें और CloudWatch को काम करने दें।
  • टेलीमेट्री (telemetry) को कभी भी अपने एजेंट को खराब न करने दें। अपने metric calls को try-except ब्लॉक्स में लपेटें (wrap करें)।
  • बर्स्ट (bursts) पर अलार्म सेट करें, एकल घटनाओं (single events) पर नहीं। एक थ्रॉटल सामान्य है। पांच मिनट में दस थ्रॉटल एक घटना (incident) है।
  • विशिष्ट एजेंटों के लिए dimensions का उपयोग करें, लेकिन सिस्टम-व्यापी लेटेंसी के लिए aggregates का उपयोग करें।
  • एरर को कोड द्वारा मैच करें, टेक्स्ट स्ट्रिंग्स द्वारा नहीं।

आप केवल लॉग्स और EMF का उपयोग करके $0 में एक प्रोफेशनल मॉनिटरिंग स्टैक बना सकते हैं।

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

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