Мониторинг AI-агентов с помощью CloudWatch
Запись каждого вызова агента в базу данных — это не мониторинг. Это просто хранение данных.
Если вам приходится запускать SQL-запросы в 2 часа ночи, чтобы проверить, не тормозит ли ваш суммаризатор, значит, вы провалили задачу по обеспечению наблюдаемости (observability). Вам нужны дашборды и алерты, а не строки в базе данных.
Я нашел два способа мониторинга AI-агентов без увеличения задержки или усложнения кода.
1. Используйте Metric Filters для отслеживания режимов сбоев
Такие режимы сбоев, как превышение лимита бюджета или троттлинг сервиса, не должны оставаться незамеченными. Не нужно писать новый код для вызова API. Вместо этого используйте существующие логи.
Когда лимит бюджета исчерпан, ваш код записывает ошибку в лог. Вы можете настроить CloudWatch Metric Filter для сканирования этих логов. Если паттерн совпадает, CloudWatch увеличивает значение метрики.
Этот метод дешев. Он не требует дополнительных разрешений IAM и не добавляет задержки вашему агенту.
Используйте это для:
- Достижения ежемесячного лимита затрат
- Ошибок троттлинга Bedrock
- Общих сбоев агентов
2. Используйте EMF для данных о производительности
Если вы хотите отслеживать задержку (latency), использование токенов или стоимость одного агента, Metric Filters будет недостаточно. Вам понадобятся измерения (dimensions).
Не используйте PutMetricData. Это синхронный сетевой вызов. Он добавляет от 30 до 80 мс к вашему запросу. Он также может завершиться ошибкой, если сам CloudWatch перегружен.
Вместо этого используйте Embedded Metric Format (EMF).
Вы записываете одну строку JSON в stdout. CloudWatch автоматически извлекает их как метрики с измерениями.
С помощью одной строки JSON вы получаете:
- Общее количество вызовов
- Частоту ошибок
- Задержку (P95)
- Входные и выходные токены
- Стоимость за модель и за агента
Правила эффективной наблюдаемости (Observability)
- Выводите строку и позволяйте CloudWatch выполнять работу.
- Никогда не позволяйте телеметрии приводить к сбоям агента. Оборачивайте вызовы метрик в блоки try-except.
- Настраивайте алерты на всплески, а не на единичные события. Один случай троттлинга — это нормально. Десять случаев троттлинга за пять минут — это инцидент.
- Используйте измерения (dimensions) для конкретных агентов, но используйте агрегаты для задержки всей системы.
- Сопоставляйте ошибки по коду, а не по текстовым строкам.
Вы можете построить профессиональный стек мониторинга за $0, используя только логи и EMF.
Источник: https://dev.to/aws-builders/monitorear-agentes-de-ia-con-cloudwatch-45c4
Дополнительное сообщество для обучения: https://t.me/GyaanSetuAi