Microsoft Agent Frameworkのtracingは、OpenTelemetryのspansとしてApplication Insightsへ送信できます。Azure Update 564071では、.NETとPython向けのtracingがpublic previewとして案内されています。実装の要点は、Agent Framework側でtracingを有効化し、Azure Monitor用のOpenTelemetry exporterをアプリケーション起動時に登録することです。(Microsoft Azure)
end-to-endで可視化するには、exporterを追加するだけでは足りません。model callを記録するchat client、agentやtool call、workflowのstate遷移という各レイヤーでinstrumentationを有効にする必要があります。.NETではsourceNameとAddSource()を一致させ、Pythonではconfigure_azure_monitor()を先に実行してからenable_instrumentation()を呼ぶのが重要です。(Microsoft Learn)
一方、public preview中はspan名、attribute名、保存先テーブル、samplingの既定値が変わる可能性があります。ダッシュボードや監視処理をraw schemaへ直接結び付けず、KQLの正規化層を挟む設計が安全です。
Agent Framework tracingをApplication Insightsへ送る全体像
Agent Framework tracingの基本構成は、次のとおりです。
ユーザー要求
└─ agent invocation
├─ model call
├─ tool call
└─ workflow
├─ executor
├─ edge routing
└─ message transfer
↓
OpenTelemetry spans
↓
Azure Monitor exporter
↓
Application Insights
↓
FoundryのTraces画面／Azure Monitor LogsAgent Frameworkのobservabilityを有効にすると、代表的には次のようなspansが生成されます。
| 可視化する処理 | 代表的なspan | 分かること |
|---|---|---|
| agent実行 | invoke_agent <agent_name> | agent全体の実行時間、エラー、子spanとの関係 |
| model call | chat <model_name> | モデル呼び出し時間、token使用量、モデル情報 |
| tool call | execute_tool <function_name> | 呼び出したtool、処理時間、成功・失敗 |
| workflow実行 | workflow.run、workflow.session、workflow_invoke | workflow全体やセッション単位の実行 |
| executor処理 | executor.process {executor_id} | 各ノードやexecutorでの処理 |
| state遷移・routing | edge_group.process、message.send | メッセージ配送、分岐、fan-in、配送失敗 |
Agent Frameworkのagent observabilityでは、agent、chat、tool callが同じtraceに含まれます。workflowでは、単純な親子関係だけでなくOpenTelemetryのlinkも使われます。例えば送信元のmessage.sendと送信先のexecutor.processは、処理が入れ子ではないため、親子ではなくlinkで関連付けられることがあります。(Microsoft Learn)
そのため、Application Insightsの画面でspanが完全なツリーになっていなくても、直ちにtrace propagationの失敗とは限りません。workflowのstate遷移を確認するときは、parent IDだけでなくspan linksも確認します。
管理者設定：導入前に決めておく項目
コードを変更する前に、管理者側で次の設定を決めておくと、導入後の作り直しを防げます。
| 設定項目 | 推奨する方針 |
|---|---|
| Application Insights | agent用に新規作成するか、既存アプリ用リソースへ統合するかを決める |
| connection string | ソースコードへ書かず、App Serviceのアプリ設定やシークレットストアで管理する |
service.name | agentや実行サービスごとに一意で分かりやすい名前を付ける |
sourceName | .NETのinstrumentationとAddSource()で同じ値を使う |
| 閲覧権限 | Logsを利用する担当者へLog Analytics Readerなど必要最小限の権限を付与する |
| 機密情報 | 本番環境ではprompt、response、tool引数・結果を原則記録しない |
| sampling | 開発、検証、本番で別々の方針を定める |
| retention | Application InsightsとLog Analyticsの保持期間・課金を確認する |
Microsoft Foundryと連携する場合は、FoundryプロジェクトにApplication Insightsを接続します。Log Analyticsのテーブルがprotected tableとして設定されている環境では、通常の閲覧権限に加えて、保護されたデータを参照できる権限が必要になる場合があります。(Microsoft Learn)
sourceNameとservice.nameは別物
両者は混同しやすいものの、役割が異なります。
sourceNameは、.NETのActivitySourceをOpenTelemetry providerが購読するための名前です。service.nameは、Application Insights上でサービスを識別する名前です。Azure MonitorではCloud Role NameやAppRoleNameとして利用されます。sourceNameが不一致だと、agentがspanを生成していてもexporterが収集しません。service.nameが重複すると、複数のagentやAPIが同じサービスとして表示され、切り分けが難しくなります。
.NETでsourceNameを省略した場合、Agent Frameworkの既定sourceはExperimental.Microsoft.Agents.AIです。独自のsourceを使う場合は、instrumentationとAddSource()の両方に同じ文字列を指定します。(Microsoft Learn)
.NETでtracingを有効化してApplication Insightsへ送る
Application Insightsのconnection stringを設定する
Azure Monitor OpenTelemetryが使用する標準の環境変数名は、次のとおりです。
APPLICATIONINSIGHTS_CONNECTION_STRING例えば、App ServiceやContainer Appsではアプリケーション設定として登録します。ローカル開発ではユーザーシークレットや環境変数を使用し、リポジトリ内の設定ファイルには直接保存しない方が安全です。(Microsoft Learn)
一部のサンプルでは、コード側で独自の環境変数名を読み込んでいる場合があります。Environment.GetEnvironmentVariable()を明示的に使うのであれば変数名自体は任意ですが、Azure Monitorが自動的に認識する標準名はAPPLICATIONINSIGHTS_CONNECTION_STRINGです。
OpenTelemetry providerとAzure Monitor exporterを登録する
コンソールアプリやWorker Serviceで使用できる最小構成は、次のようになります。
using Azure.Monitor.OpenTelemetry.Exporter;
using OpenTelemetry;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;
const string SourceName = "Contoso.AgentFramework";
const string ServiceName = "contoso-support-agent";
var connectionString =
Environment.GetEnvironmentVariable(
"APPLICATIONINSIGHTS_CONNECTION_STRING")
?? throw new InvalidOperationException(
"APPLICATIONINSIGHTS_CONNECTION_STRING is not set.");
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.SetResourceBuilder(
ResourceBuilder
.CreateDefault()
.AddService(ServiceName))
.AddSource(SourceName)
.AddAzureMonitorTraceExporter(options =>
{
options.ConnectionString = connectionString;
})
.Build();この構成で重要なのは、AddSource(SourceName)です。後述するchat client、agent、workflowのinstrumentationにも同じSourceNameを渡します。値が1文字でも違うと、そのsourceから生成されたspanは収集対象になりません。(Microsoft Learn)
ASP.NET CoreやWorker Serviceで既にOpenTelemetryをDI登録している場合は、新しいTracerProviderを別途作るのではなく、既存のtracing pipelineへAddSource(SourceName)とAzure Monitor exporterを追加します。複数のproviderやexporterを重複登録すると、同じspanが二重送信される原因になります。
chat clientとagentへinstrumentationを追加する
既存のIChatClientをbaseChatClientとしている場合、model callとagent callを記録する構成は次のようになります。
var instrumentedChatClient = baseChatClient
.AsBuilder()
.UseOpenTelemetry(
sourceName: SourceName,
configure: options =>
{
options.EnableSensitiveData = false;
})
.Build();
var agent = new ChatClientAgent(
instrumentedChatClient,
name: "SupportAgent",
instructions: "問い合わせ内容を分類し、必要なtoolを実行します."
).WithOpenTelemetry(
sourceName: SourceName,
configure: options =>
{
options.EnableSensitiveData = false;
});UseOpenTelemetry()はchat clientのmodel callを、WithOpenTelemetry()はagentの実行をinstrumentationします。両方を有効にすると詳細なtraceを取得できますが、EnableSensitiveDataも両方で有効にすると、promptやresponseなどがagent spanとchat spanの双方へ重複して記録されることがあります。(Microsoft Learn)
本番環境では、まずEnableSensitiveData = falseで開始するのが安全です。全文が必要な障害調査では、本番データをそのまま使うのではなく、検証環境で再現用データを用意して一時的に有効化します。
workflowのstate遷移もinstrumentationする
agentがAgent Framework Workflowを利用している場合、workflow builderにもWithOpenTelemetry()を適用します。
workflow telemetryでは、次の範囲を個別に制御できます。
| option | 無効化されるspan |
|---|---|
DisableWorkflowBuild | workflow.build |
DisableWorkflowRun | workflow.session、workflow_invokeなど |
DisableExecutorProcess | executor.process |
DisableEdgeGroupProcess | edge_group.process |
DisableMessageSend | message.send |
state遷移をend-to-endで確認したい場合は、DisableWorkflowRun、DisableExecutorProcess、DisableEdgeGroupProcess、DisableMessageSendを有効にしないようにします。一方、workflow定義が頻繁に生成され、workflow.buildが大量に記録される場合は、本番環境でbuild spanだけを抑制する方法があります。(Microsoft Learn)
Pythonでtracingを有効化してApplication Insightsへ送る
Azure Monitor exporterをインストールする
Agent FrameworkのPythonパッケージには、OpenTelemetryの基本パッケージは含まれますが、Application Insights用のexporterは既定ではインストールされません。
pip install azure-monitor-opentelemetryApplication Insightsへ送る場合は、azure-monitor-opentelemetryを追加します。(Microsoft Learn)
service名とconnection stringを設定する
実行環境には、少なくとも次の値を設定します。
APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=...
OTEL_SERVICE_NAME=contoso-support-agentOTEL_SERVICE_NAMEを設定しない場合、Agent Framework側の既定値が使われます。複数のagentを同じApplication Insightsへ送るときは、agentアプリや実行サービスごとに明示的な名前を設定すると、Application MapやKQLで区別しやすくなります。
Azure Monitorを先に構成してからinstrumentationを有効化する
アプリケーションの起動処理で、agentを作成・実行する前に次のコードを呼び出します。
import os
from azure.monitor.opentelemetry import configure_azure_monitor
from agent_framework.observability import (
create_resource,
enable_instrumentation,
)
configure_azure_monitor(
connection_string=os.environ[
"APPLICATIONINSIGHTS_CONNECTION_STRING"
],
resource=create_resource(),
enable_live_metrics=True,
)
enable_instrumentation(
enable_sensitive_data=False,
)順序は、次のとおりです。
configure_azure_monitor()でOpenTelemetry providerとAzure Monitor exporterを構成するenable_instrumentation()でAgent Frameworkのtelemetry生成を有効にする- agent、chat client、workflowを作成して実行する
enable_instrumentation()だけを呼んでも、送信先となるexporterがなければApplication Insightsへは届きません。反対に、Azure Monitor exporterだけを構成しても、Agent Framework側のinstrumentationが無効ならagent固有のspansは生成されません。(Microsoft Learn)
.envファイルを使う場合、Agent Frameworkが自動的に.envを読み込むわけではありません。python-dotenvなどを使う場合は、configure_azure_monitor()より前にload_dotenv()を実行します。
FoundryChatClientを使う場合の短縮設定
Microsoft FoundryのFoundryChatClientを使っている場合は、クライアントからAzure Monitorを構成できます。
await client.configure_azure_monitor(
enable_live_metrics=True
)この方法では、Foundryプロジェクトに関連付けられたApplication Insightsの情報とresource設定が利用されます。独自ホスティングやFoundry外のプロジェクトでは、前述のconfigure_azure_monitor()とenable_instrumentation()を明示する方が構成を把握しやすくなります。(Microsoft Learn)
適用範囲：どこまでtracingを有効にするか
取得範囲は、調査したい問題から逆算します。
| 適用範囲 | 主に確認できること | 向いている用途 |
|---|---|---|
| chat clientのみ | model call、latency、token使用量 | モデル性能やコストの確認 |
| agentのみ | agent実行、tool callを含む処理の流れ | agent単体のデバッグ |
| workflowのみ | executor、routing、message、state遷移 | 複雑なworkflowの分岐調査 |
| chat client＋agent | agentからmodelまでの詳細 | toolを含む一般的なagent |
| chat client＋agent＋workflow | model、tool、state遷移を含む全体 | end-to-end調査 |
読者の目的が「model call、tool call、state遷移を一つのtraceで追うこと」であれば、chat client、agent、workflowの3レイヤーを有効化するのが基本です。
ただし、全文データまで全レイヤーに保存する必要はありません。構造的なspanはすべて取得しつつ、promptやtool引数などのcontent記録は無効にする構成でも、遅延、失敗箇所、呼び出し順序、routing結果は確認できます。
Application Insightsでtracingを確認する方法
tool callとstate遷移が発生するテストを実行する
単に「こんにちは」と送るだけでは、model callしか発生しない可能性があります。確認用の入力は、次の条件を満たすようにします。
- 必ず1回以上toolを呼び出す
- workflowで2つ以上のexecutorを通る
- 条件分岐やmessage transferが発生する
- 成功ケースと失敗ケースを1回ずつ実行する
例えば、問い合わせ分類agentなら「注文番号を検索し、配送状況を取得した後、遅延していれば担当部署へ引き継ぐ」という処理を実行します。
FoundryまたはApplication Insightsで確認する
FoundryプロジェクトへApplication Insightsを接続している場合は、FoundryのObservabilityまたはTraces画面を確認します。Azure側では、Application InsightsのTransaction searchやLogsから確認できます。
tracesは即時に表示されるとは限りません。Microsoftのドキュメントでは、agent実行後に表示されるまで通常2～5分程度かかると案内されています。(Microsoft Learn)
KQLで同じOperationIdのspansを並べる
Log Analytics workspaceから確認する場合は、次のKQLを使用できます。
union withsource=TelemetryTable
AppRequests,
AppDependencies
| where TimeGenerated > ago(30m)
| where AppRoleName == "contoso-support-agent"
| project
TimeGenerated,
TelemetryTable,
Name,
OperationId,
ParentId,
DurationMs,
Success,
Properties
| order by TimeGenerated asc確認するポイントは、次のとおりです。
- 同じ要求のspanで
OperationIdが一致しているか invoke_agent、chat、execute_toolが存在するか- workflowの
executor.processやmessage.sendが存在するか - 失敗したspanの
Successやerror attributeが記録されているか AppRoleNameが意図したservice.nameになっているか
Application Insightsのresource scopeでは、requestsやdependenciesというテーブル名が使われます。Log Analytics workspaceでは、対応するテーブルがAppRequestsとAppDependenciesになります。分散tracingのspansは主にこれらのテーブルへ保存されます。(Microsoft Learn)
workflowで送信先executorが親子関係として表示されない場合は、span詳細のlinksを確認します。message.sendから送信先のexecutor.processへlinkが設定されていれば、trace contextは維持されています。
tracingが表示されないときの公式回避策と確認項目
自動連携でtraceが表示されない場合は、暗黙的な設定に依存せず、Agent FrameworkのinstrumentationとAzure Monitor exporterをコードで明示的に登録するのが確実な回避策です。
| 症状 | 主な原因 | 対処方法 |
|---|---|---|
| traceが1件も出ない | exporter未登録 | Azure Monitor exporterとconnection stringを確認する |
| .NETだけ出ない | sourceName不一致 | UseOpenTelemetry()、WithOpenTelemetry()、AddSource()を同じ値にする |
| Pythonだけ出ない | 初期化順序が逆 | configure_azure_monitor()を先に呼ぶ |
| ローカルだけ出ない | .env未読込 | load_dotenv()をtelemetry設定より前に実行する |
| model callしか出ない | agent／workflow未instrumentation | agentとworkflow側でもtracingを有効にする |
| 一部の要求だけ欠落する | sampling | 検証時は一時的に100％へ変更する |
| promptが二重に見える | chat clientとagentの双方でcontent記録 | content記録を片側だけにする |
| workflowが分断されて見える | linkを親子関係として探している | span linksを確認する |
| 数分待っても出ない | connection string、通信経路、RBAC | ingestion endpointへの通信と閲覧権限を確認する |
.NETでsourceNameを省略する場合は、AddSource("Experimental.Microsoft.Agents.AI")を登録する方法もあります。ただし、将来の変更や複数サービスの識別を考えると、独自のsourceNameを全箇所へ明示する方が管理しやすくなります。(Microsoft Learn)
また、Application Insightsへのingestion endpointがfirewallやproxyで遮断されていると、コードが正常でもtelemetryは届きません。閉域構成では、Azure Monitorの必要なendpointへの送信可否も確認します。(Microsoft Learn)
preview schemaで注意すべき変更点
Agent Framework tracingはpublic previewです。さらに、基盤となるOpenTelemetryのGenAI semantic conventionsも発展途上です。
OpenTelemetryの従来のGenAI attribute registryでは、多くのgen_ai.* attributesが別のGenAI semantic conventions repositoryへ移され、既存項目にはMovedやDeprecatedの表示があります。invoke_agent、execute_toolなどのoperation valuesもDevelopment状態として定義されています。移行先repositoryでは、schema URLが現時点でTODOとされています。(OpenTelemetry)
したがって、preview中は次の変更を想定する必要があります。
| 変わり得るもの | consumerへの影響 |
|---|---|
| span名 | Name == "workflow.run"のような完全一致検索が失敗する |
| attribute名 | KQL、Workbook、alert ruleで値を取得できなくなる |
| attributeの型 | 文字列を前提にした変換処理が失敗する |
| 親子・linkの表現 | trace treeだけを解析する処理でstate遷移を見失う |
| 保存先テーブル | promptやtool結果を既存テーブルから取得できなくなる |
| samplingの既定値 | SDK更新後に取得件数が変わる |
| content記録方式 | promptやresponseの格納位置や参照方法が変わる |
実際にworkflow observabilityのドキュメントでも、実装や言語によってworkflow.runを使う構成と、workflow.sessionおよびworkflow_invokeを使う構成が記載されています。consumer側で一つのspan名だけを前提にしないことが重要です。(Microsoft Learn)
2026年9月30日のGenAI content保存先変更に備える
Application Insightsでは、prompt、model response、system instructions、tool arguments、tool resultsなどのGenAI contentを、専用のgenAIContentテーブルへ保存します。Log AnalyticsではAppGenAIContentとして表示されます。
Microsoftの現行ドキュメントでは、2026年9月30日以降に新規ingestionされたデータについて、対象attributeの値をAppDependencies、AppTraces、AppEventsへ直接保存せず、専用テーブルへの参照情報へ置き換える予定とされています。組み込みのApplication InsightsやFoundry画面は自動的に対応しますが、既存テーブルからcontentを直接読み取る独自KQL、alert、Workbook、外部連携は見直しが必要です。(Microsoft Learn)
特に、次のような実装は避けます。
AppDependencies
| extend Prompt =
tostring(Properties["gen_ai.input.messages"])raw contentを利用するconsumerは、AppGenAIContentを含む専用のquery layerを作り、保存先テーブルの変更をそのquery layer内で吸収できる構成にします。
consumerをpreview schemaから疎結合にする方法
KQL関数でattributeを正規化する
dashboardやalertが各テーブルを直接参照するのではなく、共通のKQL関数を作ります。
let NormalizeAgentSpans = () {
union isfuzzy=true
AppRequests,
AppDependencies
| extend Attributes = Properties
| extend LogicalComponent = coalesce(
tostring(
Attributes["gen_ai.agent.name"]
),
tostring(
Attributes["workflow.name"]
),
Name
)
| project
TimeGenerated,
OperationId,
ParentId,
AppRoleName,
LogicalComponent,
Name,
DurationMs,
Success,
Attributes
};
NormalizeAgentSpans()
| where TimeGenerated > ago(1d)
| order by TimeGenerated ascattribute名が変更された場合は、dashboardを一つずつ修正するのではなく、この正規化関数に新旧両方の候補を追加します。
完全一致ではなく論理分類を使う
次のような完全一致へ過度に依存すると、span名の変更に弱くなります。
| where Name == "workflow.run"監視用途では、複数の候補を論理的なカテゴリへまとめます。
| extend OperationCategory = case(
Name startswith "invoke_agent", "agent",
Name startswith "chat", "model",
Name startswith "execute_tool", "tool",
Name startswith "workflow", "workflow",
Name startswith "executor.process", "executor",
Name == "message.send", "transition",
"other"
)この分類自体も共通関数へまとめれば、preview更新時の修正箇所を限定できます。
alertは比較的安定した信号を中心にする
本番alertでは、preview attributeよりも次の値を優先します。
service.nameに対応するAppRoleNameOperationId- spanの成功・失敗
- duration
- exception
- telemetryのingestion有無
- OpenTelemetry metrics
prompt本文やtool引数の特定文字列を直接alert条件にすると、schema変更だけでなく、個人情報や機密情報の取り扱いも複雑になります。
SDK更新時にcontract testを実行する
Agent FrameworkやOpenTelemetry関連パッケージを更新するときは、既知のテストシナリオを実行します。
検証用シナリオには、少なくとも次の処理を含めます。
- agentを1回起動する
- modelを1回呼び出す
- toolを1回呼び出す
- workflowで1回分岐する
- executor間でmessageを送る
- 意図的に1回失敗させる
その後、必要な論理カテゴリ、OperationId、エラー、durationが取得できることを自動テストします。raw attributeの完全なsnapshotを固定するのではなく、運用上必要な論理項目が正規化後に存在するかを検証するのがポイントです。
tracingを業務データの正本にしない
tracingは、障害調査や性能分析のためのtelemetryです。注文状態、承認結果、tool実行の確定履歴など、業務上保存が必要な情報をtraceだけに依存させてはいけません。
重要なstate遷移は、業務DBや監査ログへ別途保存します。OpenTelemetry traceは、その処理が遅かった理由や失敗した位置を調査する補助情報として利用します。この分離により、preview schemaやsamplingが変わっても業務処理の証跡を失いません。
samplingの設定方針
Azure Monitor OpenTelemetryでは、固定割合のsamplingと、1秒当たりのtrace数を制限するrate-limited samplingを利用できます。
.NETでは、exporter設定へ次のように指定できます。
.AddAzureMonitorTraceExporter(options =>
{
options.ConnectionString = connectionString;
// 例：全traceの10％
options.SamplingRatio = 0.1F;
})rate limitを使う場合は、次のようにします。
.AddAzureMonitorTraceExporter(options =>
{
options.ConnectionString = connectionString;
// 例：1秒当たり約1.5 trace
options.TracesPerSecond = 1.5F;
})Pythonでも同様に設定できます。
configure_azure_monitor(
connection_string=connection_string,
resource=create_resource(),
sampling_ratio=0.1,
)または、rate limitを指定します。
configure_azure_monitor(
connection_string=connection_string,
resource=create_resource(),
traces_per_second=1.5,
)Azure Monitorのドキュメントでは、固定割合の値を判断できない場合、5％から開始して実際の精度とデータ量を見ながら調整する方法が案内されています。ただし、最初の接続確認やSDK更新テストでは、samplingによる欠落と設定不備を区別するため、一時的に100％取得する方が確認しやすくなります。(Microsoft Learn)
| 環境 | samplingの目安 | content記録 |
|---|---|---|
| ローカル開発 | 100％ | 合成データに限り必要時のみ有効 |
| 結合テスト | 100％ | 原則無効 |
| staging | テスト時間帯のみ100％ | 原則無効 |
| 小規模本番 | 低い固定割合から開始 | 無効 |
| 高トラフィック本番 | rate-limitedを検討 | 無効 |
samplingは、同じtrace内のrequestやdependencyへ共通して適用されます。model spanだけ10％、tool spanだけ100％というように、標準samplerでtelemetry typeごとに異なる割合を指定することはできません。(Microsoft Learn)
また、SDKや言語によってsamplingの既定動作が異なる場合があります。取得件数を運用設計に組み込む場合は、既定値へ依存せずコードまたは環境変数で明示します。
機密情報とコストの注意点
EnableSensitiveDataやenable_sensitive_dataを有効にすると、次の情報がtelemetryへ含まれる可能性があります。
- ユーザーのprompt
- モデルのresponse
- system instructions
- functionやtoolの引数
- toolの実行結果
- workflow message
- executorのinputとoutput
これらには、氏名、メールアドレス、社内情報、検索キーワード、認証情報などが含まれる可能性があります。本番環境ではcontent記録を無効にし、構造、時間、token数、成功・失敗を中心に取得します。(Microsoft Learn)
contentを保存する必要がある場合は、次の対策を組み合わせます。
- promptやtool引数へsecretを入れない
- 個人情報を送信前にマスキングする
AppGenAIContentをprotected tableとして扱う- 閲覧者を必要最小限に限定する
- retentionを短くする
- samplingと日次ingestion量を監視する
- 開発用と本番用のApplication Insightsを分ける
Application Insightsの課金とretentionは、接続されたLog Analytics workspaceの設定にも影響されます。agent tracingを有効にした直後は、toolの多い1要求が何件のspansとどの程度のデータ量を生成するかを実測してから、本番samplingを決めます。
導入時に行うべき最終チェック
Agent Framework tracingをApplication Insightsへ送るときは、次の順序で進めます。
- Application Insightsを作成またはFoundryプロジェクトへ接続する
APPLICATIONINSIGHTS_CONNECTION_STRINGをシークレットとして登録する- agentごとに一意な
service.nameを決める - .NETでは同一の
sourceNameでinstrumentationとAddSource()を設定する - Pythonでは
configure_azure_monitor()の後にenable_instrumentation()を呼ぶ - chat client、agent、workflowの必要な範囲をinstrumentationする
- tool callとstate遷移を含むテストを実行する
- 同じ
OperationIdでmodel、tool、workflow spansを確認する - KQLの正規化層を作り、preview schemaを直接consumerへ露出させない
- 本番用のsampling、retention、機密情報ポリシーを設定する
最初の成功条件は、1回のテスト要求について、agent、model、tool、workflowの処理を同じtraceまたはlinkされたspansとして追えることです。その状態を確認してから、samplingやspan抑制でデータ量を最適化すると、設定不備とコスト調整を切り分けやすくなります。
コメント