ゲートウェイのトレースとリクエストログ:すべてのLLM呼び出しをデバッグ
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ゲートウェイでトレーシングが必要な理由
LLMの呼び出しが遅い、コストがかかる、あるいは期待通りに動作しない場合、実際に何が起きたのかを把握する必要があります。ガードレールがプロンプトを編集してしまったのか?モデルの処理時間とネットワークの遅延はそれぞれどの程度か?ゲートウェイはプロバイダーに何を送信したのか?AI Gatewayの AI Gateway は、すべての呼び出しに対してこれらの疑問に答えます。
すべてのリクエストがゲートウェイを経由するため、各アプリケーションに手動で計測機能を組み込むことなく、この可視性を確保できます。
ログ記録の制御
The リクエストログに関するドキュメント では、どのリクエストをログに記録するかを制御できます。最もシンプルな方法は、X-TFY-LOGGING-CONFIGヘッダーにJSON文字列を指定してリクエストごとに制御することです。enabledをtrueに設定するとリクエストが記録され、falseに設定するとスキップされます。
注意点として、ほとんどのSDKはヘッダーを文字列としてシリアライズするため、このヘッダーの値は生のJSONオブジェクトではなく、文字列化されたJSONである必要があります。従来のグローバルなログ記録モードは、ルールベースの ログ設定に置き換わりつつあります。これにより、サブジェクト、モデル、メタデータごとにログ記録を制御し、機密情報を編集(レッドアクション)することが可能になります。
リクエストログの表示
UIで記録されたリクエストを確認するには、「AI Gateway」から「Monitor」、「Requests」の順に進みます。ここに記録されたすべての呼び出しリストが表示され、個別のリクエストを選択して詳細を調査できます。

トレースとスパンの解説
The トレーシングに関するドキュメント トレースとは、LLMとやり取りするサービス間を流れるリクエストの完全なライフサイクルを指します。通常、トレースはアプリケーションの単一のAPI呼び出しに対応します。
スパンとは、関数呼び出し、HTTPリクエスト、モデル推論など、トレース内の個々の作業単位のことです。トレースは、親子関係を持つスパンのツリー構造であり、子スパンは通常、親スパンによって引き起こされます。TrueFoundryは、これらのトレースを保存し、クエリや分析を行うためのUIを備えたOpenTelemetryコレクターバックエンドを提供しており、OpenTelemetry互換のあらゆるSDKからトレースを受信可能です。

単一のトレースを読み解く
The トレース調査のドキュメント では、PII(個人識別情報)のマスキングガードレールを使用したチャット補完という実際の例を取り上げ、階層を形成する5つのスパンとしてキャプチャされた様子を解説します。
- ChatCompletionスパン(ルート) は、クライアント視点でのリクエストの全ライフサイクルを表します。この例では約7秒間続き、トークンメトリクス、コスト、入力、出力の情報が含まれています。
- Guardrailスパン はルートの子であり、0.5秒未満で完了するPIIマスキング処理を表します。
- Guardrailネットワークコールスパン は、ガードレールサービスへの実際のHTTP呼び出しであり、HTTPメソッドとステータスコードが含まれます。
- Modelスパン はGuardrailスパンの兄弟であり、リクエスト時間の大部分を占めるモデル推論を表します。
- Modelネットワークコールスパン は、プロバイダーへの実際のHTTP呼び出しであり、例えばプロバイダーのチャット補完エンドポイントへのPOSTリクエストなどが該当します。
同じ例において、入力データ内の名前がプレースホルダーに置き換わっていることが確認でき、PIIガードレールがトレース内でエンドツーエンドで機能していることがわかります。

ガードレール、モデル、およびアウトバウンドネットワークスパンを示すチャット補完トレース。
単一のトレースからフリート全体のメトリクスへ
個別のトレースはデバッグ用です。傾向を把握するには、 分析ダッシュボード で同じデータを集計します。タブには「概要」「モデルメトリクス」「MCPメトリクス」「ガードレールメトリクス」「ルーティングメトリクス」「キャッシュメトリクス」があります。
モデルメトリクスは、モデル、仮想モデル、ユーザー、仮想アカウント、チーム、またはメタデータごとにグループ化できます。また、レイテンシビューでは、リクエストレイテンシ、最初のトークンまでの時間、トークン間レイテンシ、出力トークンあたりの時間を詳細に分析可能です。リクエストごとのトレースと組み合わせることで、ミクロな視点とマクロなダッシュボードの両方を活用できます。

分析ダッシュボードのモデルメトリクス。チーム、ユーザー、モデルなどでグループ化が可能です。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


Recent Blogs
Frequently asked questions
How do I turn logging on or off for a request?
Send the X-TFY-LOGGING-CONFIG header with a stringified JSON value and set enabled to true or false. Remember that the value is stringified JSON, not a raw object, because most SDKs serialize headers as strings.
Where do I view logs and traces?
Logged requests appear under AI Gateway, then Monitor, then Requests. Opening a request shows its trace, which is the tree of spans covering guardrails, the model, and the outbound provider calls.
What is the difference between a trace and a span?
A trace is the full lifecycle of a single request. A span is one unit of work inside that trace, such as a guardrail check or a model inference. Spans form a parent and child tree within the trace
Can I use my own OpenTelemetry SDK?
Yes. TrueFoundry runs an OpenTelemetry collector backend and can receive traces from any OpenTelemetry compatible SDK. For LLM use cases the docs recommend an LLM focused SDK that captures model specific traces and metrics.










.png)
.png)


.png)
.png)




.png)



.png)





