Моніторинг AI-агентів за допомогою CloudWatch

Логування кожного виклику агента в базу даних — це не моніторинг. Це просто зберігання даних.

Якщо вам потрібно запускати SQL-запити о 2:00 ночі, щоб перевірити, чи не гальмує ваш суммаризатор, ви провалили побудову observability. Вам потрібні дашборди та сповіщення (alarms), а не рядки в базі даних.

Я знайшов два способи моніторингу AI-агентів без збільшення затримки (latency) або ускладнення коду.

1. Використовуйте Metric Filters для виявлення режимів відмов

Режими відмов, такі як ліміти бюджету або обмеження швидкості обслуговування (throttling), не мають бути непомітними. Не потрібно писати новий код для виклику API. Замість цього використовуйте ваші наявні логи.

Коли ліміт бюджету вичерпано, ваш код реєструє помилку. Ви можете налаштувати CloudWatch Metric Filter для сканування цих логів. Якщо шаблон збігається, CloudWatch збільшує значення метрики.

Цей метод є дешевим. Він не потребує додаткових дозволів IAM і не додає жодної затримки вашому агенту.

Використовуйте це для:

  • Досягнення місячного ліміту витрат
  • Помилки throttling у Bedrock
  • Загальні збої агентів

2. Використовуйте EMF для даних про продуктивність

Якщо ви хочете відстежувати затримку (latency), використання токенів або вартість на одного агента, Metric Filters буде недостатньо. Вам потрібні виміри (dimensions).

Не використовуйте PutMetricData. Це синхронний мережевий виклик. Він додає від 30 до 80 мс до вашого запиту. Він також може завершитися помилкою, якщо сам CloudWatch перевантажений.

Замість цього використовуйте Embedded Metric Format (EMF).

Ви записуєте один рядок JSON у stdout. CloudWatch автоматично витягує їх як метрики з вимірами (dimensions).

За допомогою одного рядка JSON ви отримуєте:

  • Загальну кількість викликів
  • Рівень помилок
  • Затримку (P95)
  • Вхідні та вихідні токени
  • Вартість за модель та за агента

Правила ефективної observability

  • Виводьте рядок і дозвольте CloudWatch виконати роботу.
  • Ніколи не дозволяйте телеметрії зламати вашого агента. Огортайте виклики метрик у блоки try-except.
  • Налаштовуйте сповіщення (alarms) на сплески, а не на поодинокі події. Один випадок throttling — це нормально. Десять випадків throttling за п'ять хвилин — це інцидент.
  • Використовуйте виміри (dimensions) для конкретних агентів, але використовуйте агрегати для загальносистемної затримки.
  • Ідентифікуйте помилки за кодом, а не за текстовими рядками.

Ви можете побудувати професійний стек моніторингу за $0, використовуючи лише логи та EMF.

Джерело: https://dev.to/aws-builders/monitorear-agentes-de-ia-con-cloudwatch-45c4

Додаткова спільнота для навчання: https://t.me/GyaanSetuAi