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

LLMシステムは、従来のAPIモニタリングでは表面化できない方法で失敗します。キューが静かに満たされ、GPUメモリがCPUが忙しくなる前に飽和し、レイテンシがアプリケーション層ではなくバッチング層で爆発します。本ガイドでは、LLM推論およびLLMアプリケーション向けのエンドツーエンドの観測性戦略について説明します。測定すべき項目、Prometheus、OpenTelemetry、Grafanaを使ってどのようにインストゥルメント化するか、そしてテレメトリーパイプラインをスケールしてデプロイする方法をカバーします。

TL;DR（実行要約）

LLMシステムは、従来の「HTTPレイテンシ＋エラーレート」モニタリングでは説明できない方法で劣化します。LLMシステム向けの**観測性**は、迅速かつ説得力のある答えを提供する必要があります：

• ユーザー体験が劣化しているかどうか（テールレイテンシ、ファーストトークン到達時間、トークン間レイテンシ、エラーや中止）。
• 時間がどこに使われているか（キューイング vs バッチング vs モデル実行；リトリーバル/ツール/セーフティフィルタ vs 推論）。
• 何が最初に飽和するか（GPU利用率およびメモリ圧力、KVキャッシュ/キュー圧力、CPUトークナイズ）。
• コストおよび容量がどのように変化するか（リクエストごとのトークン数、GPUごとのトークン/秒、キャッシュヒット率、無駄な生成）。
• テレメトリが安全に保存できるかどうか（プロンプトにPIIが含まれる可能性があるため、ログ/属性に機密情報が漏洩しないようにする）。

最も頑健な設計はマルチシグナルパイプラインです：

• メトリクスで迅速な検出および容量計画（Prometheus + PromQL；オプションで長期保存はThanos/Cortex/Mimir/VictoriaMetricsを使用）。
• トレースでリクエストレベルの因果関係（OpenTelemetryとOTLP；バックエンドはTempo/Jaeger/Zipkin/Elastic APM）。
• ログで文脈を提供しトレースと関連付ける（Loki/Elastic/OpenSearch）、低カーディナリティメタデータ向けに設計。
• プロファイリングでCPU/メモリホットスポットおよびテールレイテンシ（Grafana Pyroscope）。
• 合成＋ロードテストでユーザーが検出する前に回帰を検出（Grafana k6；ブラックボックススタイルのプローブ）。
• SLOでユーザーの成果を測定し、行動可能なアラートを駆動（エラーバジェット；バーンレートスタイル）。

LLMシステム向け観測性の違い

範囲の注意点: 対象LLMフレームワークは未指定です。この記事の例は一般的なサーバー/フレームワーク（Triton、vLLM、TGI、LangChain/LangSmith）をカバーし、同等のメトリクスおよびスパンを代入することで他のスタックにも適用可能です。

LLMは、従来のウェブサービスと異なる運用行動を導入します：

• リクエストごとの変動作業: トークン数（入力/出力）は広範囲に変動するため、「リクエスト/秒」は安定しているように見えるが、トークンスループットは崩壊する可能性があります。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エンドポイントをエクスポートし、そのドキュメントには生成トークンのカウンターやtime to first tokenなどのヒストグラムが含まれます。
• Hugging Face TGIはキューのサイズ、バッチのサイズ、エンドツーエンドのリクエストの所要時間、生成されたトークン、キューの所要時間が含まれる/metricsエンドポイントをドキュメント化しています。

核心的な観測性タスクおよび必要なLLMテレメトリ

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

メトリクス: オンラインサービングシステムでは、Prometheusの独自のインストゥルメント化ガイドラインはクエリ数、エラー、およびレイテンシを主要なメトリクスとして強調します。LLMはこれにTTFT、トークンごとのスループット/レイテンシ、キューの長さ、バッチのサイズ、GPU利用率を追加します。

トレース: トレースはリトリーバル/ツール/セーフティ/推論段階におけるレイテンシおよび失敗を属性付ける方法です。OpenTelemetryはトレース/エクスポーターをベンダー中立の方法として、コレクターやバックエンドにテレメトリを発行および送信するためのフレームワークとしています。

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

プロファイリング: 連続的なプロファイリングは低オーバーヘッドのサンプリングで生産CPU/メモリの動作を捕捉します。Grafana Pyroscopeはこれに明示的に位置づけられています。

合成テストおよびロードテスト: Grafana k6はオープンソースのロードテストツールであり、Grafanaは合成モニタリングが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はプルが先です。 プロセスはサポートされているエクスポジション形式でメトリクスを公開し、Prometheusは設定されたスクレイプジョブに従ってそれらをスクレイプします。

プッシュは例外です。 Prometheusの「プッシュゲートウェイの使用場面」ガイドでは、プッシュゲートウェイを限られたケース（一般的なプッシュ置き換えではない）にのみ明示的に推奨し、プッシュゲートウェイのREADMEでは「Prometheusをプッシュベースのモニタリングシステムに変えることはできない」と強調しています。

LLM特有の実用的なパターン：

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

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

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

Kubernetesでは、OpenTelemetry Operator（アノテーションベースの注入）を使用してサイドカー注入がサポートされています。

LLMスタックの実用的なルールオブサム：

• デーモンセットエージェントを使用してホストレベルの豊富化および多くのポッドをまたいで共有されたパイプラインを使用します。
• サイドカーを使用して厳密なワークロードごとの分離またはローカルフィルタリング（プロンプトに機密データが含まれる可能性がある場合に一般的）が必要な場合に使用します。
• ゲートウェイコレクターを使用して中央集約されたテールサンプリング、バッチング、リトライ、およびエクスポートファンアウトに使用します。

サンプリングおよびカーディナリティ制御

OpenTelemetryはテールサンプリングがトレースから導出された基準を使用してサンプリング決定を可能にすることを明確にしています（ヘッドサンプリングのみでは不可能）。

Prometheusのインストゥルメント化ガイドラインはラベルの過剰使用を警告し、カーディナリティを低く保つためのルールオブサムを提供し、潜在的なカーディナリティが約100を超える場合にメトリクスを再設計することを奨励しています。

LLM特有の「カーディナリティトラップ」を早期に排除する必要があります：

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

制限された次元を優先する: model, model_family, endpoint, region, status_code, deployment, tenant（制限がある場合のみ）。

LLM観測性ツールの比較

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

可視化におけるGrafanaと代替品の比較

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

メトリクスバックエンドにおけるPrometheusと代替品の比較

• Prometheusローカルストレージのデフォルト: 保留フラグが設定されていない場合、保留は15dにデフォルトします（保留/コストを早期に計画）。
• 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例

# 5分間のアプリケーションヒストグラムの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プロトコルであり、ソース、コレクター、バックエンド間のテレメトリのエンコード/トランスポートを定義しています。
• OpenTelemetry SDK設定は、OTEL_EXPORTER_OTLP_ENDPOINT（およびプロトコルオプション）などの環境変数を使用してテレメトリのエクスポートを文書化しています。
• OpenTelemetry Python contribは、FastAPIの自動および手動インストゥルメント化をサポートするFastAPIインストゥルメント化を文書化しています。
• GenAIセマンティックコンベンションは、GenAIコンベンション移行のためのOTEL_SEMCONV_STABILITY_OPT_INを介してオプトインの安定性メカニズムを含んでいます。

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

以下のスニペットでは次のことが示されています：

• Prometheusメトリクスのエクスポージョン（/metrics）、「PrometheusでLLM推論をモニタリング」
• 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ローカルストレージ: 明示的なサイズ/時間フラグがない場合、保留時間は15dにデフォルトします。
• Prometheusリモートライティング: Prometheusは「健全なデフォルト」を超えてスケーリングするためのリモートライティング調整を文書化しています。
• Grafana Tempo: 高スケールトレースバックエンドとして位置づけられ、スパンからメトリクスを生成するためにmetrics-generatorを使用できます（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/ディスク/ネットワークコストを増加させることを警告し、カーディナリティガイドラインを提供。
• ヒストグラムの誤用
  • _bucketシリーズからrate()およびleを使用してクォンタイルを計算することを確認してください（Prometheusはヒストグラムクォンタイル計算のトレードオフを説明）。
• トレースサンプリングのギャップ
  • 頭部サンプリングを過剰に行うと、レアな遅延/エラートレースが消える；テールサンプリングは全体のトレース基準に基づいて「重要な」トレースを保持。
• Tempo span-metricsの問題
  • Tempo metrics-generatorおよびspan-metricsを使用している場合、それが有効化および調整されているかを確認（Tempoはmetrics-generatorおよびspan-metricsプロセッサを文書化；generatorの問題のトラブルシューティングが存在）。
• GPUメトリクスの欠如
  • DCGMエクスポーターがデプロイされており、/metricsがリーチ可能であることを確認（DCGMエクスポーターはPrometheusのためにHTTP経由でGPUメトリクスをエクスポート）。

有用なリンク

• 観測性: モニタリング、メトリクス、Prometheus & Grafanaガイド
• Prometheusモニタリング: 設定およびベストプラクティス
• LLMパフォーマンス: ベンチマーク、ボトルネック & 最適化
• LLMホスティング: ローカル、セルフホスト、クラウドインフラストラクチャの比較
• RAGステップバイステップチュートリアル
• Prometheus構成ドキュメント
• Prometheusエクスポージョンフォーマット
• 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エクスポーター仕様
• PrometheusがOTLPを受けるためのガイド
• LangSmithとOpenTelemetryのトレース