本文へ移動
Telemetry
統合ガイド

AutoGen タスク フロー、状態、タイムアウトの監視

AutoGen タスクフローの状態、タイムアウト、チームとエージェントの結果、ツールのアクティビティ、ハンドオフ、遅延、障害、コスト、リリースをコンパクトな構造化イベントで追跡します。

レビュー者 Telemetry 製品チーム . インストルメンテーション契約、プライバシー境界、および実装ガイダンス. 基準と所有権を確認する

クレジット カードは必要なく、サンプル実行は自動的に作成されます。再利用可能なコーディング エージェント ワークフローについては、「 エージェント テレメトリ skill.md ガイド.

役に立つ
  • AutoGen マルチエージェント監視
  • タスクフローのタイムアウトと状態遷移の監視
  • エージェントハンドオフ分析
  • ツールループと終端の信頼性
測定経路

AutoGen タスクフローのタイムアウトを制限された結果に変える

メッセージ、タスク テキスト、ツール ペイロード、または無制限の停止理由をコピーすることなく、チーム境界で最後に承認されたワークフローの状態と構成されたタイムアウトをキャプチャします。

  1. 1

    チームがスタート

    安定した実行 ID、ワークフロー、チーム名、リリース、および制限された開始状態を割り当てます。

  2. 2

    タスクフローの実行

    結果の境界でハンドオフ、ツール、メッセージをカウントしながら、メッセージとツールの詳細を追跡します。

  3. 3

    タイムアウトが最終的になる

    timed_out、timeout_ms、最後に承認された状態、および有界終了カテゴリを記録します。

  4. 4

    SQL が回帰を発見

    ワークフロー、チーム、リリース別にタイムアウト率、期間、ハンドオフを比較します。

始める前に

前提条件と境界

  • AutoGen と telemetry-sh が信頼できる Python プロセスで初期化される
  • アプリケーションが所有する実行 ID と安定したチーム、ワークフロー、モデル、終了、およびリリース名
  • 詳細な AutoGen トレースが必要な場合は、OpenTelemetry エクスポートを個別に構成します

配信設定

サーバー側のインストールと初期化

サーバー側キーを使用して、プロセスごとに 1 回、同期コードの場合は Telemetry を、非同期コードの場合は TelemetryAsync を初期化します。 ブラウザ バンドル、クライアントに表示される環境変数、ソース管理、ログ、および例外メッセージに取り込み資格情報が含まれないようにします。

autogen-インストール

pipのインストール

bash
python -m pip install telemetry-sh
  1. 1制限されたネットワーク動作を持つ再利用可能なサーバー側配信クライアントを 1 つ準備します。
  2. 2成功、失敗、再試行、またはタイムアウトの境界に結果イベントを追加します。
  3. 3アラートを有効にする前に、制御されたフィクスチャを送信し、保存されている行を検査します。

スニペット

1 つの構造化されたイベントから始める

ワークフローが完了、失敗、または再試行される場所にこの図形を追加します。次に、実際のフィールドからダッシュボードを構築します。

autogen

AutoGen Task Flow, State, and Timeout Monitoringイベント

python
import asyncio
from time import perf_counter

async def run_agent_team(team, task: str, run_id: str):
    started_at = perf_counter()
    status = "success"
    error_type = None
    state_before = "team_started"
    state_after = "team_completed"
    timeout_ms = 120_000
    result = None

    try:
        result = await asyncio.wait_for(
            team.run(task=task),
            timeout=timeout_ms / 1000,
        )
        return result
    except TimeoutError:
        status = "timed_out"
        error_type = "team_timeout"
        state_after = "timeout_reached"
        raise
    except Exception as error:
        status = "failed"
        error_type = classify_agent_error(error)
        state_after = "team_failed"
        raise
    finally:
        await telemetry.log("agent_run_completed", {
            "run_id": run_id,
            "workflow": "support_resolution",
            "team_name": "support_team",
            "status": status,
            "error_type": error_type,
            "state_before": state_before,
            "state_after": state_after,
            "timeout_ms": timeout_ms,
            "timed_out": status == "timed_out",
            "termination_reason": getattr(result, "stop_reason", None),
            "message_count": len(result.messages) if result else 0,
            "duration_ms": round((perf_counter() - started_at) * 1000),
            "release": APP_RELEASE,
        })

イベント契約

run_id、ワークフロー、team_name、agent_count、model_alias、termination_reason、リリース

ステータス、duration_ms、message_count、tool_call_count、handoff_count、および error_type

バインド・タスク・フロー診断用のstate_before、state_after、timeout_ms、timed_out、およびtermination_reason

estimated_cost_usd、承認済み、human_handoff、evaluation_score、および承認時の環境

実装のチェックポイント

チェックポイント 1

パブリック エージェントまたはチームの実行境界をラップし、1 つの最終結果を出力します。特定のクエリがその粒度を必要とする場合を除き、メッセージごとに 1 つのビジネス イベントを避けてください。

チェックポイント 2

構成されたタイムアウトと最後に承認されたワークフロー状態を使用して、タイムアウトを最終結果として扱います。単にトリガーされたノードから成功を推測しないでください。

チェックポイント 3

AutoGen は、詳細なエージェントとツールの実行のための OpenTelemetry トレースをサポートしています。これらのトレースを OTLP 互換のバックエンドに保存し、承認された識別子によって結果を関連付けます。

チェックポイント 4

デフォルトでは、タスク テキスト、エージェント メッセージ、ツール引数、ツール結果、メモリ、無制限の停止メッセージ、または例外テキストを決して出力しません。

検証

イベントが到着したことを証明する

既知の成功例と失敗例を実行した後、これを実行します。最終的なイベント コントラクトがスニペットと異なる場合は、フォールバック テーブル名を置き換えます。

autogen-検証

AutoGen Task Flow, State, and Timeout Monitoring 検証クエリ

sql
SELECT *
FROM agent_run_completed
ORDER BY timestamp_utc DESC
LIMIT 20;
論理結果ごとに 1 つのターミナル行を、予想されるステータス、識別子、単位、および UTC 時刻とともに確認します。
推論されたスキーマを検査し、再試行によってフィールド タイプが変更されたり、新しい論理イベント ID が生成されたりしないことを確認します。
保存されたフィールドで認証情報、生のペイロード、プロンプト、プライベート コンテンツ、および無制限のエラー メッセージを検索します。
ダッシュボードを完了として扱う前に、プロバイダーのタイムアウト、取り込みの拒否、およびプロセスのシャットダウンを実行します。

実装の参考資料

新しい運用パスを有効にする前に、イベント契約、データ安全性に関するガイダンス、上流の主要ドキュメントを確認してください。

生産境界

結果イベントを小さく、回復可能なものに保つ

このパターンが提供するのは、

  • 上流のワークフローの横にある、制限付きの SQL 対応の結果。
  • ダッシュボード、アラート、およびイベント間の相関関係の安定したフィールド。
  • 成功、失敗、再試行、タイムアウトの動作を検証するためのフィクスチャ駆動のパス。

このパターンでは提供されません

  • OTLP エクスポーター、自動収集パイプライン、または詳細なトレースと診断ログの代替。
  • ペイロードにイベント ID が含まれているという理由だけで、1 回だけ配信されます。
  • 生のプロバイダー ペイロード、ユーザー コンテンツ、資格情報、または規制されたデータを収集する許可。

イベントスキーマの開始点

クエリまたはスニペットを運用環境に適用する前に、行粒度、出力境界、必要なタイプ、プライバシー クラス、サンプル ペイロード、および検証チェックリストを確認してください。

関連製品の機能

このワークフローを続行します AIエージェントの監視

レビュー可能な SQL を使用して、エージェントの実行、ツールの使用、モデルのコスト、品質、製品の結果を結び付けます。

関連する SQL レシピ

SQL で次の質問に答えてください

このワークフローの構造化フィールドに対してクエリを実行し、結果の例を検査して、有用な回答をダッシュボードまたはアラートに変換します。

すべてのレシピを参照する
完全なコレクションAIとLLM SQL構造化イベント SQL

実装ファミリーごとに参照する

関連する統合パターンを比較する

この統合と組み合わせるテンプレート

さらなる統合