Skip to main content
Una buena observabilidad de TokenLab comienza con identificadores públicos. Tus registros deberían ayudarte a responder “¿qué solicitó el usuario, qué tarea pública creó TokenLab y cómo se facturó?” sin exponer detalles sensibles del proveedor ni datos sensibles del usuario.

De la solicitud al diagnóstico y al soporte

  1. Abre Solicitudes en el espacio de trabajo propietario. Busca el Request ID y selecciona la fila.
  2. Abre los detalles completos en una página independiente. Al volver a la lista se restauran los filtros. Un enlace no concede acceso a otro espacio; usa una cuenta autorizada.
  3. Si el estado está pendiente o es desconocido, actualiza primero el progreso. Ante un fallo o una respuesta interrumpida, inicia la investigación disponible en el Agent integrado. No vuelve a enviar la solicitud original al modelo. Las solicitudes correctas no necesitan investigación por defecto.
  4. Si necesitas ayuda, elige soporte humano desde la solicitud o investigación. Revisa la vista previa y los enlaces a la solicitud y conversación cuando estén disponibles, elimina datos privados y envía explícitamente. Abrir una investigación o vista previa no envía una solicitud al soporte.
  5. Guarda la confirmación y continúa la misma conversación en Soporte para recibir respuestas y añadir información, evitando duplicados.

Identificadores Públicos a Capturar

No almacenes IDs de tareas del proveedor, URLs del proveedor, identificadores del proveedor, claves de Redis o metadatos de ejecución sensibles como registros visibles para el cliente.

Qué Registrar

Registra lo suficiente para diagnosticar la solicitud sin filtrar secretos:
  • Endpoint, método HTTP, modelo, código de estado, marca de tiempo y latencia.
  • Identificadores públicos: request_id, task_id, poll_url y billing_transaction_id cuando estén presentes.
  • Forma de solicitud sanitizada: qué campos estaban presentes, no el prompt completo o contenido de medios privados.
  • Respuestas de estado asíncronas terminales, incluidos campos de error públicos.
  • Conteo de reintentos del cliente y si el reintento creó una nueva tarea o reanudó una existente.
Siempre redacta Authorization, claves de API, tokens de gestión, URLs firmadas, URLs de medios privados, prompts completos y datos personales del usuario a menos que tengas permiso explícito para retenerlos.

Matriz de Solución de Problemas

Conciliación de Uso

Utiliza la API de Gestión para la conciliación del lado del servidor:
GET /v1/management/api-keys/{keyId}/usage puede filtrar por scene, model, modelVendor, startDate y endDate. Utiliza estos registros en lugar de raspar páginas del panel o depender de IDs de tareas del proveedor ascendente. Las respuestas de streaming pueden liquidarse después de que se envía el stream, por lo que un encabezado de facturación puede estar ausente incluso cuando el uso se registra más tarde. Las tareas de medios asíncronas pueden liquidarse después del sondeo terminal.

Plantilla de Paquete de Soporte

Al contactar soporte, incluye:
  • request_id.
  • task_id y poll_url para trabajos asíncronos.
  • billing_transaction_id cuando esté presente.
  • Endpoint, método, modelo, marca de tiempo y código de estado.
  • Forma de solicitud sanitizada y cuerpo de error público.
  • Tu resultado esperado y lo que el usuario realmente vio.
No incluyas claves de API, tokens de gestión, medios privados, prompts completos, URLs del proveedor, IDs de canales o identificadores privados de diagnóstico a menos que el soporte de TokenLab solicite explícitamente una muestra redactada.

Comprobaciones Operativas

  • Alerta sobre respuestas repetidas 401, 402, 429 y 5xx por separado; generalmente tienen diferentes propietarios.
  • Rastrea trabajos asíncronos que permanecen no terminales más allá de tu SLA de producto.
  • Rastrea intentos de creación duplicados para el mismo ID de trabajo de usuario.
  • Muestra trabajos completados y verifica que el activo visible para el usuario, el registro de uso y el registro de tarea almacenado coincidan.

Referencia de API