LLM API分析（トランザクション連携）
AI Agent ObservabilityはWhaTap APMと統合されており、LLM API呼び出しをアプリケーショントランザクションの一部として追跡します。トランザクションプロファイルでLLM HTTPCステップをクリックするとLLM API詳細Drawerが開き、プロンプト入力/出力、トークン使用量、コスト、エラー情報はもちろん、GPUインフラストラクチャの相関関係まで1つの画面で確認できます。
プロンプト入力/出力の照会にはログ読み取り権限が必要です。
アクセス方法
- LLMダッシュボードのヒットマップまたはトランザクション検索などからトランザクションを選択します。
- トランザクションプロファイル画面でLLM HTTPCステップ（LLMプロバイダURLへのHTTP外部呼び出し）をクリックします。
- 右側にLLM API詳細Drawerが開きます。
サマリーおよびプロンプト
LLM呼び出しの主要情報を一目で確認でき、プロンプト入力/出力の原本を確認できる領域です。
Identityタグ
呼び出し対象のモデルとプロバイダ情報をタグ形式で表示します。
| Tag | Description | Example |
|---|---|---|
Model | 使用されたLLMモデル名 | gpt-4o, claude-sonnet-4-20250514 |
Provider | LLM APIプロバイダ | api.openai.com, api.anthropic.com |
Operation | 呼び出しのOperation Type | chat, completion |
呼び出しが失敗した場合（success=false）、赤色のErrorタグが追加で表示されます。
主要数値指標
Identityタグの横にインラインで表示されます。
| Metric | Description |
|---|---|
Token | 全体トークン数（Input + Output） |
Cost | 該当呼び出しのコスト（$） |
Latency | リクエスト開始～応答完了時間（ms） |
HTTP情報
| Property | Description |
|---|---|
URL | 呼び出しエンドポイント（host:port + path） |
Elapsed | HTTP呼び出し所要時間（ms） |
Step ID | このLLM呼び出しの固有識別子。ログ検索への遷移基準キーです。 |
Step ID横のログ検索ボタンをクリックすると、該当Step IDでフィルタリングされたログエクスプローラーが新しいウィンドウで開きます。
エラー情報
呼び出しにエラーが発生した場合のみ表示されます。
| Property | Description |
|---|---|
Error Class | エラークラス名（例: RateLimitError、TimeoutError） |
Error Message | エラー詳細メッセージ |
プロンプト入力（Input）
折りたたみ/展開が可能なセクションで、LLMに送信された入力メッセージを表示します。
ヘッダーバッジ
| Badge | Description |
|---|---|
Input Tokens | 入力トークン数 |
Cached Tokens | キャッシュから取得したトークン数（該当する場合のみ表示） |
Input Cost ($) | 入力コスト |
メッセージタイプ
| Label | Description |
|---|---|
| SYSTEM | システムメッセージ。モデルの役割と動作を定義する指示文です。 |
| USER | ユーザー入力メッセージ。実際のプロンプト内容です。 |
メッセージがチャンク（chunk）に分割されて収集された場合、自動的に正しい順序で組み立てて完全なテキストとして表示します。
モデル応答（Output）
折りたたみ/展開が可能なセクションで、モデルが生成した応答を表示します。
ヘッダーバッジ
| Badge | Description |
|---|---|
Output Tokens | 出力トークン数 |
Reasoning Tokens | 推論（Reasoning）トークン数（該当する場合のみ表示） |
Output Cost ($) | 出力コスト |
メッセージタイプ
| Label | Description |
|---|---|
| ASSISTANT | モデルのテキスト応答です。 |
| TOOL CALL | モデルがリクエストしたツール呼び出し（Function Calling）の内容です。 |
| TOOL RESULT | ツール呼び出しの実行結果です。 |
GPU 相関関係
マルチトランザクション（mtidが存在する場合）の場合、Drawer右側に表示されます。LLM呼び出しを処理したPodのGPUインフラストラクチャ状態をリアルタイムチャートで表示し、モデル応答遅延がGPUリソース不足によるものかを判断できます。
GPU情報ヘッダー
| Property | Description |
|---|---|
Pod | LLM推論を実行したKubernetes Pod名 |
| Pod詳細ボタン | クリックするとKubernetesモニタリングのPod詳細ページが新しいウィンドウで開きます。 |
GPUチャート
LLM呼び出し時点の前後5分範囲のGPUメトリクスをラインチャートで表示します。
| Chart | Metric | Unit | Description |
|---|---|---|---|
| GPU Utilization | DCGM_FI_DEV_WEIGHTED_GPU_UTIL | % | GPU演算リソースの使用率。100%に近い場合、GPUが飽和状態であり、LLM応答遅延の原因となる可能性があります。 |
| VRAM Usage | DCGM_FI_DEV_FB_USED | MiB | GPUメモリ（Video RAM）使用量。モデルのロードと推論に使用され、不足するとOOMやスワップが発生します。 |
| GPU Temperature | DCGM_FI_DEV_GPU_TEMP | °C | GPU温度。過熱時に自動スロットリングが発生し、性能が低下します。 |
| Power Usage | DCGM_FI_DEV_POWER_USAGE | W | GPU電力消費。Utilizationと合わせて確認すると、実際の演算負荷を把握できます。 |
GPU相関関係は以下の条件がすべて満たされた場合に表示されます。
- トランザクションがマルチトランザクション（mtid存在）の場合
- LLM推論を実行したPod名が識別された場合
- 連携されたKubernetesプロジェクトでDCGM GPUメトリクスが収集されている場合
分析シナリオ
LLM応答遅延の原因特定
- LLMダッシュボードのヒットマップで応答時間が長いトランザクションをクリックします。
- トランザクションプロファイルでLLM HTTPCステップのElapsed時間を確認します。
- LLM API詳細Drawerを開いてLatency値とGPU Utilizationチャートを比較します。
- GPU Utilizationが高い状態でLatencyが急増している場合、GPUリソース不足が原因です。
- GPU Utilizationが低いのにLatencyが高い場合、プロバイダ側の遅延（キュー待ち、Rate Limitなど）を疑います。
エラー発生LLM呼び出しの再現
- トランザクションプロファイルでエラーが表示されたLLM HTTPCステップをクリックします。
- DrawerのError ClassとError Messageでエラータイプを確認します。
- **プロンプト入力（Input）**セクションでSYSTEMメッセージとUSERメッセージの原本を確認します。
- 収集されたプロンプト原本とモデル/パラメータ情報で同一の呼び出しを再現し、問題を分析します。
コストが高いLLM呼び出しの分析
- コスト分析ページでコストが高い時間帯を特定します。
- 該当時間帯のトランザクションを検索してプロファイルを開き、LLM HTTPCステップをクリックします。
- DrawerでToken数とCostを確認します。
- プロンプト入力セクションでInput Tokensバッジを確認し、プロンプトが不必要に長くないか確認します。
- Cached Tokensバッジが0の場合、キャッシングが適用されていない呼び出しのため、キャッシング対象のプロンプトかどうかを検討します。
参考
データ収集構造
LLM API詳細Drawerは2つのデータソースを組み合わせています。
| Data Source | Description | Usage |
|---|---|---|
| APMトレース | HTTP呼び出し情報（URL、host、port、elapsed、エラークラス/メッセージ）、Step ID | トランザクションプロファイルでの呼び出し識別およびHTTPレベル情報表示 |
#LlmCallLogログ | モデル、プロバイダ、トークン、コスト、成功可否、メッセージ内容 | プロンプト原本復元およびLLMレベルメタデータ表示 |
2つのデータはStep IDを基準に連結されます。
メッセージチャンク組み立て
LLMプロンプトと応答は長くなる場合があるため、サーバーで複数のチャンク（chunk）に分割して収集されます。Drawerはchunk_indexフィールドを基準にチャンクを正しい順序で組み立て、完全なメッセージを復元します。タイプ当たり最大100個のチャンクまでサポートします。