Skip to main content
Une bonne observabilité de TokenLab commence par des identifiants publics. Vos journaux devraient vous aider à répondre à la question “qu’est-ce que l’utilisateur a demandé, quelle tâche publique TokenLab a-t-il créée, et comment a-t-elle été facturée ?” sans exposer de détails fournisseur sensibles ni de données utilisateur sensibles.

​
Identifiants Publics À Capturer

Ne stockez pas les ID de tâches du fournisseur, les URLs du fournisseur, les identifiants fournisseur, les clés Redis ou les métadonnées d’exécution sensibles comme enregistrements visibles par le client.

​
Ce Qu’il Faut Enregistrer

Enregistrez suffisamment d’informations pour diagnostiquer la demande sans divulguer de secrets :
  • Point de terminaison, méthode HTTP, modèle, code d’état, horodatage et latence.
  • Identifiants publics : request_id, task_id, poll_url, et billing_transaction_id lorsqu’ils sont présents.
  • Forme de demande assainie : quels champs étaient présents, pas l’intégralité de l’invite ou du contenu média privé.
  • Réponses de statut asynchrone terminales, y compris les champs d’erreur publics.
  • Compte de tentatives du client et si la tentative a créé une nouvelle tâche ou a repris une tâche existante.
Toujours masquer Authorization, clés API, jetons de gestion, URLs signées, URLs de médias privés, invites complètes et données personnelles de l’utilisateur à moins que vous n’ayez une autorisation explicite de les conserver.

​
Matrice de Dépannage

​
Réconciliation d’Utilisation

Utilisez l’API de Gestion pour la réconciliation côté serveur :
GET /v1/management/api-keys/{keyId}/usage peut filtrer par scene, model, modelVendor, startDate, et endDate. Utilisez ces enregistrements au lieu de scraper les pages de tableau de bord ou de vous fier aux ID de tâches du fournisseur en amont. Les réponses de streaming peuvent se régler après l’envoi du flux, donc un en-tête de facturation peut être absent même lorsque l’utilisation est enregistrée ultérieurement. Les tâches de médias asynchrones peuvent se régler après un polling terminal.

​
Modèle de Packet de Support

Lors de la prise de contact avec le support, incluez :
  • request_id.
  • task_id et poll_url pour le travail asynchrone.
  • billing_transaction_id lorsqu’il est présent.
  • Point de terminaison, méthode, modèle, horodatage et code d’état.
  • Forme de demande assainie et corps d’erreur public.
  • Votre résultat attendu et ce que l’utilisateur a réellement vu.
N’incluez pas de clés API, de jetons de gestion, de médias privés, d’invites complètes, d’URLs de fournisseur, d’ID de canal ou d’identifiants de diagnostic privés, sauf si le support TokenLab demande explicitement un échantillon masqué.

​
Vérifications Opérationnelles

  • Alertez sur les réponses répétées 401, 402, 429, et 5xx séparément ; elles ont généralement des propriétaires différents.
  • Suivez les travaux asynchrones qui restent non terminaux plus longtemps que votre SLA produit.
  • Suivez les tentatives de création en double pour le même ID de travail utilisateur.
  • Échantillonnez les travaux complétés et vérifiez que l’actif visible par l’utilisateur, l’enregistrement d’utilisation, et l’enregistrement de tâche stocké sont d’accord.

​
Référence API