LLM AWS での可観測性: AgentCore スパン宛先の監査

AWS での LLM 可観測性 に対する実際的な答えは、「CloudWatch ダッシュボードを開く」ことではありません。まず、Amazon Bedrock AgentCore がスパンを配信する場所を証明し、次に証拠がまだ含まれている可能性のあるすべての宛先を検索し、セッションとトレースの ID を検証し、古い観察を拒否し、目的の外部結果の別の受信にトレースを結合します。 AgentCore の宛先は変更される可能性があるため、この順序は重要です。現在の AWS ドキュメントには、サポートされている新しいエージェントはエージェントごとのログ グループにスパンを送信できる一方、古い構成では共有 aws/spans グループが使用される可能性があると記載されています。 0.18.0 より前の ADOT バージョンでは、統合宛先設定が無視されます。設定を変更しても古いスパンは移動されません。したがって、今日のログ グループのみに対するクエリでは、不足している証拠が以前の構成で正確に配置されていた場合でも、誤った「テレメトリなし」診断が生成される可能性があります。 このガイドでは、その境界に対するコンテンツのない監査を構築します。これは、リソース ID、バージョン、宛先、タイムスタンプ、相関識別子、実行状態、およびブール結果の受信を使用します。プロンプト、応答、ツールの引数、シークレットは必要ありません。 証拠がないと判断する前に証拠を見つけ出す AgentCore の可観測性 AgentCore リソースの組み込みメトリクスを提供し、メトリクス、スパン、ログを Amazon CloudWatch に保存します。重要な境界は、組み込みメトリックがアプリケーション トレースと同じではないということです。 AWS はメモリ リソースのデフォルト スパンを文書化していますが、エージェントのランタイムとゲートウェイ トレースの詳細はインストルメンテーションに依存します。 これにより、次の 3 つの別々の質問が作成されます。 1. AWS 観察パスは有効になっていますか? CloudWatch Transaction Search が有効になっている必要があり、トレースセグメントの宛先は CloudWatch Logs である必要があります。 2. 現在のスパンはどこに配置されるべきですか? 答えは、統合宛先の設定、リージョンのサポート、エージェントの経過時間、実行ロール、および ADOT のバージョンによって異なります。 3. 過去のスパンはどこに残るのですか? AWS は既存のスパン データを移行しないため、切り替え前に使用された宛先は調査ウィンドウの一部として残ります。 の AgentCore 構成ガイド 特に有用な運用境界を示します。エージェントごとの統合配信には aws opentelemetry distro =0.18.0 が必要です。以前のバージョンでは設定が無視され、スパンが共有グループに配信されます。同じガイドでは、関連する CloudWatch Logs リソース ポリシーをインストールするための権限が必要です。 これらの事実を使用して、クエリを実行する前に予想される宛先を計算します。 観察 予想される現在の検索範囲 オペレーターの結論 トランザクション検索が無効になっています まだどれも信頼できるものではありません セットアップを修正します。エージェントの健康状態を推測しないでください CloudWatch Logs にルーティングされないトレースセグメント まだどれも信頼できるものではありません 宛先の前提条件を修正する 統合要求、 0.18.0 以下の ADOT 共有 aws/spans 空白のエージェントごとのグループはクエリ範囲エラーです 統合されたアクティブおよびロール ポリシーが許可される エージェントごとのランタイム ログ グループ そこで現在のスパンを確認してください レビュー期間中に目的地が変更されました 現在および以前のグループ 両方を検索してください。古いスパンは着陸した場所に留まります このテーブルは意図的に単一の「テレメトリの存在」チェックではありません。エージェントごとのグループでレコードが欠落している場合は、セットアップの失敗、配信のブロック、古い ADOT バージョン、または共有グループ内の正しい履歴レコードが考えられます。これらの州では異なる修理が必要です。 目的地の移行記録を保持する アクティブな設定を唯一の真実の情報源にしないでください。 Runbook の横に小さな移行レコードを保存します。 レコードにはプロンプトまたは応答のコンテンツは含まれません。これは、ダッシュボードでは後で再構築できないクエリ計画の質問、つまりどの宛先がインシデント ウィンドウと重複しているかという質問に答えます。 移行を意識した AgentCore 監査を実行する この記事で使用された監査では、11 件の修正されたケースが評価されています。その入力コントラクトは意図的に小さくなっています。 その決定順序は構文よりも重要です。 生成されたフィクスチャに対して分類器を実行すると、次のようになります。 このケースでは、トランザクション検索の無効化、間違ったトレース先、エージェントごとのグループでのみクエリされる古い ADOT、切り替え後の履歴証拠の省略、配信権限の不足、現在のスパンの欠落、古い証拠、壊れた相関関係、正当な承認の待機、誤った完了、および正常な移行を認識した結果が取り上げられます。 これは意思決定テストであり、実際の AWS アカウントに関する証明ではありません。独自の構成とカナリア クエリからの入力を調整します。順序を維持します。そうしないと、一般的な telemetry missing 判定によって、オペレーターが間違った場所を検索したという、より実用的な事実が隠蔽されてしまう可能性があります。 セッション ID、トレース ID、および鮮度を保持する AWS では、AgentCore の可観測性を階層として説明しています。つまり、セッションにはトレースが含まれ、トレースにはスパンが含まれます。の テレメトリのドキュメント その階層を明示的にします。これは、ID がリクエスト パスに存続する場合にのみ役立ちます。 ADOT で計測された AgentCore ランタイム呼び出しについては、構成ガイドに 2 つの伝播の詳細が記載されています。 X Amzn Bedrock AgentCore Runtime Session Id を送信して、セッション ID がダウンストリーム テレメトリに到達するようにします。 トレース ID を伝播する必要がある場合は、 traceId=<traceId を使用してランタイムを呼び出します。 これらの識別子が存在するかどうかを記録し、機密ペイロードのコンテキストを記録しません。参加可能なセッションがないスパンでも、コードが実行されたことを証明できますが、セッション レベルのインシデント タイムラインをサポートすることはできません。それを correlation broken として分類し、健全ではありません。 新鮮さにも同様に明示的な契約が必要です。先週見つかった痕跡は、現在配達が機能していることを証明するものではありません。定義する： ワークフローの予想されるリズムとインシデントの許容範囲から最大経過時間を選択します。毎分カナリアにとっては 5 分が妥当です。夜間のバッチでは無理です。 「新鮮な」状態を検査可能な状態に保つために、判定とともにしきい値を保存します。 待つには証拠も必要です。トレースに所有者との限定された承認の依存関係が示され、実行が再開可能な場合は、 waiting を返します。新しいツール スパンが表示されなかったからといって、ページをスタックとしてページングしないでください。承認レコードが存在しない、矛盾している、または期限切れの場合は、 uncertain を返すか、ランブックに従ってエスカレーションします。 トレース後に結果の受信を要求する 完全なトレースは、「インスツルメントされた実行パスは終了しましたか?」という質問に答えます。 「意図した動作が行われたか?」という質問には必ずしも答えられません。 この違いは、一般的な失敗に見られます。 アップロード ツールは、宛先がオブジェクトをコミットする前に戻ります。 メッセージ API はリクエストを受け入れますが、メッセージは目的のチャネルに到達しません。 エージェントはローカル ファイルを書き込みますが、必要なアーティファクトはリモート ストレージに属します。 ダウンストリーム トランザクションがすでにロールバックされた後、最後のモデル呼び出しは成功します。 承認待ちが誤って終了成功に変換されます。 AWS の規範的なガイダンス LLM の証拠と下流への影響を相関させることを推奨しています。プライバシーを最小限に抑えた実装では、結果の受信を使用してこれを行うことができます。 レシートは、オブジェクト HEAD 、安定したキーによって読み取られたデータベース、公開 API フェッチ、チェックサム、またはターゲット テストなど、利用可能な最も強力な決定性チェックによって生成される必要があります。オブジェクトの本文、プロンプト、応答、またはシークレットを含めることはできません。 2 つの評決を分けておいてください。 証拠を追跡する 結果の受領書 州 欠落している、または古い どれでも 可観測性の証拠が不十分 完了 ない false complete 記録された承認を待っています まだ期待されていません waiting 完全かつ新鮮 存在し確認済み このテスト結果の healthy 最後の行はスコープ付きです。これは、すべてのルート、すべてのタスク、またはセマンティック出力品質ではなく、固定されたカナリアと宛先を証明します。 コンテンツを収集せずに監査を導入する 有用な製造受領書には、障害層を区別するのに十分なデータのみが必要です。 編集またはハッシュされた形式のエージェント リソースとエンドポイント識別子。 地域と観察時間。 トランザクションの検索とトレース先のステータス。 ADOT のバージョンと統合宛先設定。 現在および以前の宛先クラス。 両方の宛先が調査ウィンドウで検索されたかどうか。 一致する最新のカナリア時間。 セッション ID とトレース ID の存在。 実行状態と制限付き承認状態。 安定した操作のアイデンティティと決定的な結果の受信ステータス。 プロンプト テキスト、モデルの応答、ツールの引数、認証情報、生のヘッダー、および顧客のペイロードをこのレシートに含めないようにしてください。特定のインシデントに対して詳細なコンテンツ検査が必要な場合は、それを個別に承認し、範囲を指定します。 監査にも限界があります。すべてのアプリケーション ルートにわたるインストルメンテーションのカバレッジ、サンプリングの完全性、CloudWatch の保持、エクスポートの回復、またはセマンティックな回答の品質を証明するものではありません。これは、選択された証拠パスが構成され検索可能であること、カナリアが新鮮で相関していること、および選択された外部結果が独自のレシートを持っていることを証明します。 これは、オペレータが間違ったスパン宛先を検索したためにエージェントを変更するという、高価なカテゴリ エラーを防ぐのに十分です。 Sidewisp は現在プライベートプレビュー段階です。 その意図された役割は、目的地のカバレッジ、鮮度、相関関係、待機状態、結果の検証などの証拠を明確な健全性の観点に変えることです。 Production AgentCore および CloudWatch モニタリング アダプターは現在出荷されていないため、この記事は現在適用できる運用パターンであり、Sidewisp がすでにこの監査を実行していると主張するものではありません。