中級呼び出し元 + 管理者

症状からトラブルシューティング:z-request-id で 401 / 502 / ストリーム断を特定

401 / 403 / 404 / 502 / 503 / タイムアウト / ストリーム断 / OOM を z-request-id でエンドツーエンドに追跡し、推測をやめられます。

コミュニティが実際に不満を言っていること

StackOverflow で頻出する質問:「プロキシを通したらストリーミングのレスポンスが 1 つの塊になった」「ツール呼び出しの JSON が組み立たない」「この 429 はレート制限かクォータ超過か」「この 502 はゲートウェイかベンダーか」。

AI 呼び出しのトラブルシューティングは難しいものです。多段の経路、ストリーミング、一貫しないエラーコード。何かが壊れたとき、どのホップか分かりません。

GateLLM の実現方法

GateLLM は各リクエストに z-request-id を付与し、ログ全体を通します。症状から特定できます。401 / 403 → 認証と Header ACL、404 → ルーティング、502 / 503 → アップストリームの健全性、タイムアウト → レート制限と越境、ストリーム断 → バッファリングと SSE、OOM → 設定。

エラーコードは正規化され(クロスベンダーのエラーセマンティクスを統一)、ストリーミングはバッファリングせずネイティブに通し、Token Ops のログは照会・エクスポートできます。

実際に効果が出る 5 つのレバー

  • z-request-id がログ全体を通るため、ID で一発特定
  • 症状からの切り分け:401 / 403 / 404 / 502 / 503 / タイムアウト / ストリーム断 / OOM
  • エラーコードの正規化:クロスベンダーのエラーセマンティクスを 1 つの語彙に統一
  • ネイティブなストリームのパススルー。バッファリングせず、SSE やツール呼び出しを壊さない
  • Token Ops のログは照会・エクスポートでき、トラブルシューティングと照合に使える
詳細手順:症状からのトラブルシューティング(docs)

FAQ