CloudWatch による AI エージェントのモニタリング
すべてのエージェント呼び出しをデータベースに記録することは、モニタリングではありません。それは単なるストレージです。
要約機能が遅くなっていないかを確認するために、午前2時に SQL クエリを実行する必要があるなら、オブザーバビリティとしては失敗しています。必要なのはデータベースの行ではなく、ダッシュボードとアラームです。
レイテンシを増やしたり、複雑なコードを追加したりすることなく、AI エージェントをモニタリングする2つの方法を見つけました。
1. 失敗モードに Metric Filters を使用する
予算上限やサービスのサービストロッリングのような失敗モードは、見えない状態であってはなりません。API を呼び出すための新しいコードを書くのではなく、既存のログを活用してください。
予算上限に達した際、コードはエラーをログに記録します。CloudWatch Metric Filter を設定してそれらのログをスキャンするようにします。パターンが一致すると、CloudWatch がメトリクスをインクリメントします。
この方法は低コストです。追加の IAM 権限は不要で、エージェントへのレイテンシも発生しません。
以下の用途に使用してください：
- 月間のコスト上限到達
- Bedrock のスロットリングエラー
- 一般的なエージェントの失敗
2. パフォーマンスデータに EMF を使用する
レイテンシ、トークン使用量、またはエージェントごとのコストを追跡したい場合、Metric Filters だけでは不十分です。ディメンションが必要です。
PutMetricData は使用しないでください。これは同期的なネットワークコールです。リクエストに 30ms から 80ms の遅延が追加されます。また、CloudWatch 自体に負荷がかかっている場合に失敗することもあります。
代わりに、Embedded Metric Format (EMF) を使用してください。
stdout に 1 行の JSON を書き出すだけです。CloudWatch がこれらをディメンション付きのメトリクスとして自動的に抽出します。
1 行の JSON で、以下が得られます：
- 総呼び出し回数
- エラー率
- レイテンシ (P95)
- 入力および出力トークン
- モデル別およびエージェント別のコスト
効率的なオブザーバビリティのルール
- 1 行を出力し、あとは CloudWatch に任せる。
- テレメトリによってエージェントを停止させない。メトリクスの呼び出しは try-except ブロックで囲む。
- 単発のイベントではなく、バースト（急増）に対してアラームを設定する。1 回のスロットリングは正常ですが、5 分間に 10 回のスロットリングが発生するのはインシデントです。
- 特定のエージェントにはディメンションを使用し、システム全体のレイテンシには集計値を使用する。
- エラーはテキスト文字列ではなく、コードで一致させる。
ログと EMF だけを使用して、0 ドルでプロフェッショナルなモニタリングスタックを構築できます。
Source: https://dev.to/aws-builders/monitorear-agentes-de-ia-con-cloudwatch-45c4
Optional learning community: https://t.me/GyaanSetuAi