LLMシステムの可観測性：本番環境におけるメトリクス、トレース、ログ、およびテスト

LLM（大規模言語モデル）システムは、従来のAPIモニタリングでは検知できない方法で失敗します。キューが静かに埋め尽くされ、CPUが忙しい状態になる遥か前にGPUメモリが飽和し、レイテンシはアプリケーションレイヤーではなくバッチ処理レイヤーで急増します。

本ガイドでは、LLM推論およびLLMアプリケーション向けの観測性戦略について包括的に解説します。何を測定し、Prometheus、OpenTelemetry、Grafanaを用いてどのように計装し、テリメトリパイプラインをどのように大規模にデプロイするかを説明します。

完全なアシスタントスタックは、生推論の上に検索、ツール呼び出し、ルーティングを追加します。AIアシスタントアーキテクチャは、これらのレイヤーの中で観測性がどの位置づけになるかを明確に示しています。

TL;DR（実行要約）

LLMシステムは、従来の「HTTPレイテンシ＋エラーレート」モニタリングでは説明できない方法で劣化します。プロダクショングレードの**LLMシステム向けの観測性**は、迅速かつ根拠を持って以下の問いに答える必要があります。

• ユーザー体験が劣化しているかどうか（尾部レイテンシ、最初のトークンまでの時間（TTFT）、トークン間レイテンシ、エラー、中断）。
• 時間がどこに費やされているか（キューイングvsバッチ処理vsモデル実行；検索/ツール/セーフティフィルターvs推論）。
• 何が最初に飽和するか（GPU利用率とメモリ圧力、KVキャッシュ/キュー圧力、CPUトークン化）。
• コストと容量のドリフト（リクエストあたりのトークン数、GPUあたりのトークン/秒、キャッシュヒット率、無駄な生成）。
• テリメトリの保存が安全かどうか（プロンプトにPIIが含まれる可能性があるため、ログ/属性への機密情報の漏洩を防ぐ）。

最も強靭な設計は、マルチシグナルパイプラインです。

• メトリクス: 迅速な検知とキャパシティプランニングのため（Prometheus + PromQL；Thanos/Cortex/Mimir/VictoriaMetricsによるオプションの長期ストレージ）。
• トレース: リクエストレベルの因果関係のため（OTLPを使用したOpenTelemetry；Tempo/Jaeger/Zipkin/Elastic APMなどのバックエンド）。
• ログ: トレースに関連付けられたコンテキストのため（Loki/Elastic/OpenSearch）、低カーディナリティメタデータ用に設計。
• プロファイリング: CPU/メモリのホットスポットと尾部レイテンシのため（Grafana Pyroscope）。
• 合成テスト＋ロードテスト: ユーザーが気づく前に回帰を検知するため（Grafana k6；ブラックボックス式のプロービング）。
• SLO: ユーザー結果を測定し、実行可能なアラートを駆動するため（エラーバジェット；バーンレート方式）。

LLMシステムの観測性を特別にする要因

範囲に関する注記: 対象となるLLMフレームワークは特定されていません。この記事の例は一般的なサーバー/フレームワーク（Triton、vLLM、TGI、LangChain/LangSmith）をカバーしており、同等のメトリクスとスパンに置き換えることで他のスタックにも適用可能です。

LLMは、従来のWebサービスとは異なる運用上の振る舞いを導入します。

• リクエストあたりの作業量の変動: トークン数（入力/出力）は大きく変動するため、「リクエスト毎秒数」は安定して見える一方で、トークンスループットは崩壊する可能性があります。TGIとvLLMは、この種のモニタリングをサポートするために、トークン関連およびトークンレイテンシ関連のテリメトリを明示的にエクスポートします。
• キューイング＋継続的バッチ処理: スループットはバッチ処理/キューの規則に依存します。キューサイズとバッチサイズが一次指標となります（TGIは両方を公開しています）。
• ストリーミングUX: ユーザーは完全なレスポンス時間と同じくらい、TTFTやトークン間レイテンシを重視します。OpenTelemetryは、GenAIのセマンティック規約の下で、サーバーのTTFTやトークン毎時間を標準化しています。
• GPU圧力が失敗モードを支配: GPU利用率とGPUメモリ（使用メモリを含む）は信頼性の中心です。NVIDIAのDCGMエクスポートャーは、Prometheus /metrics エンドポイントでGPUテリメトリを公開するために特別に存在します。
• マルチステップパイプライン: 検索、ツール呼び出し、セーフティフィルター、後処理により、エンドツーエンドのレイテンシは複数のスパン/キューの構成要素となります。これにより、分散トレーシングと慎重なメトリクス設計が不可欠になります。

人気のある推論サーバーからの具体的な例がこれを強調しています。

• NVIDIA Triton Inference Server は /metrics（一般的には :8002/metrics）経由でプレーンテキストとしてメトリクスを公開し、メトリクスの有効化/無効化やメトリクスポートの選択を制御するフラグを提供します。
• vLLM は vllm: プレフィックスを持つ広範なPrometheus /metrics エンドポイントを公開しています。そのドキュメントには、生成トークンのカウンターや最初のトークンまでの時間などのヒストグラムが含まれています。
• Hugging Face TGI は、キューサイズ、バッチサイズ、エンドツーエンドリクエスト継続時間、生成トークン、キュー継続時間を含む /metrics エンドポイントを文書化しています。

基本的な観測性タスクと必要なLLMテリメトリ

LLMシステムの観測性は、タスク→シグナル→ツールをマッピングし、最初の日からカーディナリティとサンプリングを制限することで、最も簡単に実装できます。

メトリクス: オンラインサービングシステムにおいて、Prometheus自身の計装ガイダンスは、クエリ数、エラー、レイテンシを主要メトリクスとして強調しています。LLMはこれにTTFT、トークン毎のスループット/レイテンシ、キュー長、バッチサイズ、GPU利用率を追加します。

トレース: トレースは、検索/ツール/セーフティ/推論ステージ間でレイテンシや失敗を帰属させる方法です。OpenTelemetryは、トレース/エクスポートャーをベンダー中立なテリメトリの送信およびコレクターやバックエンドへの送信方法として枠組み化しています。

ログ: ログは人間が読めるコンテキストと「なぜ」を提供しますが、無制限の値のインデックス作成を避けない限り、大規模では使用できません（例: Lokiはラベルのみをインデックスし、圧縮されたログチャンクをオブジェクトストレージに保存します）。

プロファイリング: 継続的プロファイリングは、低オーバーヘッドのサンプリングでプロダクションのCPU/メモリ振る舞いをキャプチャします。Grafana Pyroscopeはこれに明示的に位置づけられています。

合成テストとロードテスト: Grafana k6はオープンソースのロードテストツールであり、GrafanaはSynthetic Monitoringがk6によって駆動され、単なるプロトコルチェックを超えていると述べています。

SLO: GoogleのSREガイダンスは、SLOをSLIによって測定されるサービスレベルの目標値/範囲として定義し、SLOのアラート化（精度/再現性/検出時間のトレードオフ）に関するガイダンスを提供しています。

主要LLMメトリクスブループリント

標準化のためのOpenTelemetry GenAIセマンティック規約

OpenTelemetryは、GenAIメトリクス用の標準命名を提供するGenAIセマンティック規約（ステータス：「開発中」）を提供しています。

• gen_ai.client.token.usage および gen_ai.client.operation.duration
• gen_ai.server.request.duration、gen_ai.server.time_per_output_token、および gen_ai.server.time_to_first_token

この標準化は、「OpenTelemetryによるLLMモデルのモニタリング」戦略のポータブルなレバーとして実用的です：一度送信し、後に同じテリメトリをOSSまたはベンダーバックエンドにルーティングします。

テリメトリパイプラインの設計

プル vs プッシュ

Prometheusはプルファーストです。 プロセスはサポートされる exposition 形式でメトリクスを公開し、Prometheusは構成されたスケープロブに従ってそれらをスクレイプします。

プッシュは例外用です。 Prometheusの「Pushgatewayを使用するタイミング」ガイドは、Pushgatewayを限られたケースでのみ（一般的なプッシュの代替としてではなく）使用することを明示的に推奨しており、PushgatewayのREADMEは、それが「Prometheusをプッシュベースのモニタリングシステムに変える」ことができないことを強調しています。

LLM固有の実践パターン:

• 推論サーバー/エクスポートャー（Triton/vLLM/TGIメトリクスエンドポイント；DCGMエクスポートャー；ノードメトリクス）にはプルを使用します。
• トレース/ログ/OTelメトリクスにはOTLPプッシュを使用します（OpenTelemetry Protocolは、ソース、コレクター、バックエンド間のトランスポート/エンコーディング/配信を定義します）。
• 単一のPrometheusを超えてスケーリングする際にリモライトを使用します（Prometheusはリモライトのチューニングガイダンスを提供し、Mimir/Thanos/Cortexは長期および/またはHAストレージオプションを提供します）。

エージェント vs サイドカー vs ゲートウェイコレクター

OpenTelemetryは、エージェントデプロイメントパターンを文書化しており、ここでテリメトリはアプリケーションまたは同じホスト（サイドカー/DaemonSet）で動作するコレクターに送信され、その後エクスポートされます。

Kubernetesの場合、サイドカーの挿入はOpenTelemetry Operator（注釈ベースの挿入）によってサポートされています。

LLMスタックのための実用的な経験則:

• ホストレベルのエンリッチメントと多くのポッド間の共有パイプラインにはDaemonSetエージェントを使用します。
• 厳格なワーカーロードごとの分離や専用ローカルフィルタリングが必要な場合はサイドカーを使用します（プロンプトに機密データが含まれる可能性がある場合によく見られます）。
• センタライズされた尾部サンプリング、バッチ処理、リトライ、エクスポートのファンアウトにはゲートウェイコレクターを使用します。

サンプリングとカーディナリティ制御

OpenTelemetryは、尾部サンプリングが、トレースから派生した基準を使用してサンプリング決定を可能にする（単なるヘッドサンプリングでは不可能）ことを明確にしています。

Prometheusの計装ガイダンスは、ラベルの過剰使用を警告し、カーディナリティを低く保つための経験則を提供し、潜在的なカーディナリティが〜100を超える場合はメトリクスを再設計するよう助言します。

早期に禁止すべきLLM固有の「カーディナリティ罠」:

• プロンプトテキスト、レスポンステキスト、会話ID、リクエストIDをラベル/属性として使用。
• ツール引数ブロブをスパン属性として使用。
• 無制限の「user_id」ラベル。

有界なディメンションを優先: model、model_family、endpoint、region、status_code、deployment、tenant（有界の場合のみ）。

LLM観測性ツールの比較

観測性タスクにマッピングされたツール

可視化におけるGrafana vs 代替ツール

• Grafanaダッシュボードは、データソース（LokiおよびMimirを含む）をクエリしてチャートや可視化を生成するパネルで構成されます。
• Kibanaは、Elastic Stack内のUIレイヤーとしてダッシュボード/可視化を提供します。
• OpenSearch Dashboardsは、OpenSearchのためのデータ可視化ツールを提供します。
• InfluxDataのドキュメントは、ChronografをInfluxエコシステム内の可視化コンポーネントとして位置づけています。

メトリクスバックエンドにおけるPrometheus vs 代替ツール

• Prometheusローカルストレージのデフォルト: 保持期間フラグが設定されていない場合、保持期間はデフォルトで15日です（早期に保持期間/コストを計画）。
• Grafana Mimirは、PrometheusおよびOpenTelemetryメトリクス用の水平スケーラブル、HA、マルチテナントの長期ストレージと説明されます。
• Thanosは、長期ストレージ機能を持つ高可用性Prometheusセットアップと説明されます。
• Cortexは、PrometheusおよびOpenTelemetryメトリクス用の水平スケーラブル、HA、マルチテナントの長期ストレージソリューションと自己説明します。
• VictoriaMetrics Cloudは、長期ストレージのためのPrometheusリモライト統合を文書化しています。
• Amazon Managed Service for Prometheusは、インジェスト/クエリのニーズに合わせてスケーリングし、PromQLとリモライトをサポートするマネージドオファリングを説明しています。

実践的実装クックブック

今日実装すべきメトリクス名とタイプ

OpenTelemetry GenAIセマンティック規約（ステータス：開発中）は、すぐに標準化できるメトリクス名を定義しています。

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

すぐにスクレイプできるサーバー側例:

• vLLMのPrometheusエンドポイントには、カウンター（例: 生成トークン合計）とヒストグラム（TTFT）が含まれ、model_name ラベル戦略を文書化しています。
• TGIは、キューサイズ、リクエスト継続時間、生成トークン、および平均トークン毎時間を含むメトリクスを文書化しています。
• Tritonは /metrics の公開とメトリクストグルを文書化しています。

LLMレイテンシとスループットダッシュボードのためのPromQL例

# アプリケーションヒストグラムのp95エンドツーエンドレイテンシ
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# エラーレートパーセント（5xx）
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# すべてのモデル横断的なトークン/秒（出力）
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGIキューサイズ（ゲージ）
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Prometheusのヒストグラムガイダンスは、ヒストグラムパーセンタイルが histogram_quantile() を使用してバケットからサーバー側で計算されることを説明しています。

LLMシステムのためのOpenTelemetry計装ノート

• OTLPは、OpenTelemetry Protocolであり、テリメトリがソース、コレクター、バックエンド間でどのようにエンコード/伝送されるかを指定します。
• OpenTelemetry SDK設定は、テリメトリのエクスポートのための環境変数（OTEL_EXPORTER_OTLP_ENDPOINT およびプロトコルオプションなど）を文書化しています。
• OpenTelemetry Python contribは、自動および手動計装のためのFastAPI計装サポートを文書化しています。
• GenAIセマンティック規約には、GenAI規約の移行のための OTEL_SEMCONV_STABILITY_OPT_IN によるオプトイン安定性メカニズムが含まれています。

短いPython例: メトリクス＋トレース＋ログ

以下のスニペットは、次のことをデモンストレーションします。

• 「PrometheusによるLLM推論のモニタリング」のためのメトリクス公開（/metrics）
• OTLP経由のエクスポートされたOpenTelemetryトレース（ベンダー中立）
• トレースコンテキストと相関する構造化ログ、プライバシーセーフデフォルト（生プロンプトをログに記録しない）

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (プルベースメトリクス)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLPトレース)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM推論API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- ロギング (プライバシーセーフデフォルト) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Prometheusメトリクス ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLMリクエスト合計",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "エンドツーエンドLLMリクエストレイテンシ (秒)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- OpenTelemetryトレーサープロバイダー ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # OTEL_EXPORTER_OTLP_* 環境変数経由で設定
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # 完全なプロンプトのログ記録を避ける；安全なメタデータを送信
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # 実際のLLM呼び出しに置き換える (Triton/vLLM/TGIクライアント)
        time.sleep(0.15)
        output = "モデルからのこんにちは。"

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # ポリシーが許可しない限り、生プロンプト/出力を含めないこと。
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

デプロイ、スケーリング、セキュリティ、およびトラブルシューティング

デプロイオプション

スケーリングと保持：実践的制約

• Prometheusローカルストレージ: 明示的なサイズ/時間フラグがない場合、保持期間はデフォルトで15日です。
• Prometheusリモライト: Prometheusは、「健全なデフォルト」を超えてスケーリングするためのリモライトのチューニングを文書化しています。
• Grafana Tempo: 高規模トレーシングバックエンドとして位置づけられ、メトリクスジェネレーターを使用してスパンからメトリクスを生成できます（Prometheusデータソースへのリモライト）。
• Lokiストレージ: Lokiのドキュメントは、ラベルのみインデックスと圧縮チャンクストレージ（オブジェクトストレージ）を強調しており、ラベル戦略がスケーリングとコストの中心であることを示しています。

セキュリティとプライバシー：プロンプトにPIIが含まれる可能性がある

OpenTelemetryのセキュリティガイダンスは、テリメトリ収集が不注意に機密/個人情報をキャプチャする可能性があることを強調しており、適切な処理はあなたの責任です。

Prometheusのセキュリティモデルは、Prometheusエンドポイントを公開ネットワーク（インターネットなど）に公開すべきではないと警告しています。なぜなら、それらはモニタリング対象システムに関する情報を提供するためです。

「LLMシステムの観測性」を安全に保つ運用プライバシー制御:

• デフォルトで生プロンプト/レスポンスをログに記録しないこと；代わりにトークン数、モデル名、レイテンシ、トレースIDをログに記録します。
• コレクター/パイプラインで機密属性を削除/ドロップする（コレクターレベルのフィルタリングはエコシステム全体で一般的なアプローチです）。
• ログ/トレースのRBACと保持ポリシーを強制する；適切な場合に機密データスキャンを検討する（例: ベンダーはテリメトリ用のスキャンャーを文書化しています）。

トラブルシューティングチェックリスト

GrafanaダッシュボードのLLMレイテンシが正しくないように見える場合、この順序でデバッグします。

• インジェストヘルス
  • Prometheus: スケープの成功と設定セマンティクスを検証する（Prometheus設定はスケープジョブ/インスタンスを定義）。
  • OTLP: エクスポートャーエンドポイント設定を確認する（SDKは OTEL_EXPORTER_OTLP_ENDPOINT とプロトコル設定を使用）。
• スキーマ不整合
  • ダッシュボードは model を期待しているが、サーバーは model_name を送信している（vLLMは明示的に model_name ラベルを文書化）。
• カーディナリティ爆発
  • 誰かがリクエストID/プロンプトハッシュでラベル付けした；PrometheusはラベルセットがRAM/CPU/ディスク/ネットワークコストを増加させることを警告し、カーディナリティガイダンスを提供しています。
• ヒストグラムの誤用
  • rate() と le を使用して _bucket シリーズからパーセンタイルを計算することを確認；Prometheusはヒストグラムパーセンタイル計算のトレードオフを説明しています。
• トレースサンプリングのギャップ
  • ヘッドサンプリングを過度に実行すると、稀な遅い/エラートレースが消えます；尾部サンプリングは、完全なトレース基準に基づいて「重要な」トレースを保持します。
• Tempoスパンメトリクス問題
  • Tempoメトリクスジェネレーターとスパンメトリクスを使用している場合、それが有効化およびチューニングされていることを確認（Tempoはメトリクスジェネレーターとスパンメトリクスプロセッサを文書化；ジェネレーター問題のトラブルシューティングが存在）。
• GPUメトリクスの欠落
  • DCGMエクスポートャーがデプロイされ、/metrics が到達可能であることを確認（DCGMエクスポートャーはPrometheus用にHTTP経由でGPUメトリクスをエクスポート）。

有用なリンク

• AIアシスタントにおけるポーリングエージェント: 11の実装パターン — 観測性チェックリストセクションは、プロダクションポーリングシステムのために計装すべき背景エージェントメトリクス、ログフィールド、管理者ビューを正確にカバー
• 観測性: モニタリング、メトリクス、Prometheus & Grafanaガイド
• A2A vs MCP: AIエージェントは本当に両方のプロトコルが必要か？ — 観測性とセキュリティセクションは、両方のプロトコルを組み合わせるマルチエージェントシステムで何をトレースするかをカバー
• マルチエージェントオーケストレーションパターン — 観測性セクションは、各パターン固有の分散トレーシング要件をカバー：スワームのための黒板リプレイ、エージェント毎のコスト帰属、メッシュのための収束モニタリング
• 2026年のGoogle A2Aプロトコル: 採用、過熱、および現実 — セキュリティと一般的なミステイクセクションは、A2A境界をまたいでエージェントをデプロイする際に必要な観測性を正確にカバー
• A2Aプロトコルとは？エージェントカードとタスクの説明 — 観測性セクションは、クロスエージェントタスクトレースが何をキャプチャする必要があるかを説明：タスクステート変更、委任チェーン、アーティファクト、およびエージェント間メッセージ
• Prometheusモニタリング: セットアップ＆ベストプラクティス
• LLMパフォーマンス: ベンチマーク、ボトルネック＆最適化
• LLMホスティング: ローカル、セルフホスト＆クラウドインフラストラクチャの比較
• RAGステップバイステップチュートリアル
• Prometheus設定ドキュメント
• Prometheus exposition 形式
• Prometheus計装ベストプラクティス
• Prometheusメトリクス命名
• Prometheusヒストグラムとサマリー
• Prometheusアラートルール
• Prometheusアラート概要
• Alertmanager設定
• GrafanaダッシュボードJSONモデル
• Grafanaプロビジョニング
• NVIDIA Triton Inference Serverメトリクス
• TorchServeメトリクスAPI
• NVIDIA DCGMエクスポートャー
• kube-prometheus-stack Helmチャート
• Prometheus Operator入門
• OpenTelemetry Prometheusエクスポートャー仕様
• OTLP受信のためのPrometheusガイド
• OpenTelemetryによるLangSmithトレーシング