中級呼び出し元 + 管理者
症状からトラブルシューティング: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 のログは照会・エクスポートでき、トラブルシューティングと照合に使える