リクエストから調査、サポートへ
- リクエストの所属ワークスペースでリクエストを開き、Request ID を探して行を選択します。
- 詳細全体を専用ページで開けます。一覧に戻るとフィルターが復元されます。リンクで他のワークスペースへの権限が付与されることはありません。権限のあるアカウントを使用してください。
- 保留中や不明な状態では、まず進行状況を更新します。失敗や応答の中断では、表示される調査操作からアプリ内 Agent を起動できます。元のモデルリクエストは再送されません。正常に成功したリクエストは、通常は調査不要です。
- 解決しない場合は、リクエストや調査から人によるサポートを選択します。プレビューと、利用可能なリクエスト・会話へのリンクを確認し、私的な内容を削除して明示的に送信してください。調査やプレビューだけではサポートに送信されません。
- 送信確認を保存し、サポートの同じ会話で返信や追加情報をやり取りしてください。重複した依頼は不要です。
キャプチャすべき公開識別子
プロバイダーのタスク ID、プロバイダー URL、プロバイダー識別子、Redis キー、または機密性の高い実行メタデータを顧客向け記録として保存しないでください。
ログに記録する内容
秘密を漏らさずにリクエストを診断するために十分な情報をログに記録してください：- エンドポイント、HTTPメソッド、モデル、ステータスコード、タイムスタンプ、レイテンシ。
- 公開識別子：
request_id、task_id、poll_url、およびbilling_transaction_idが存在する場合。 - サニタイズされたリクエスト形状：どのフィールドが存在したか、完全なプロンプトやプライベートメディアコンテンツではなく。
- ターミナル非同期ステータス応答、公開エラーフィールドを含む。
- クライアントの再試行回数と、再試行が新しいタスクを作成したか、既存のタスクを再開したか。
Authorization、APIキー、管理トークン、署名付きURL、プライベートメディアURL、完全なプロンプト、およびユーザーの個人データを常に削除してください。
トラブルシューティングマトリックス
使用の調整
サーバーサイドの調整にはManagement APIを使用してください：GET /v1/management/api-keys/{keyId}/usageはscene、model、modelVendor、startDate、およびendDateでフィルタリングできます。ダッシュボードページをスクレイピングしたり、上流プロバイダーのタスクIDに依存する代わりに、これらの記録を使用してください。
ストリーミング応答はストリームが送信された後に決済される場合があるため、使用が後で記録される場合でも請求ヘッダーが存在しないことがあります。非同期メディアタスクはターミナルポーリングの後に決済される場合があります。
サポートパケットテンプレート
サポートに連絡する際は、以下を含めてください：request_id。- 非同期作業のための
task_idとpoll_url。 - 存在する場合は
billing_transaction_id。 - エンドポイント、メソッド、モデル、タイムスタンプ、ステータスコード。
- サニタイズされたリクエスト形状と公開エラーボディ。
- あなたの期待する結果とユーザーが実際に見たもの。
操作チェック
- 繰り返しの
401、402、429、および5xx応答にアラートを出す；通常、異なるオーナーがいます。 - 製品SLAよりも長く非ターミナルのままの非同期ジョブを追跡します。
- 同じユーザージョブIDの重複作成試行を追跡します。
- 完了したジョブをサンプリングし、ユーザーが見えるアセット、使用記録、および保存されたタスク記録が一致することを確認します。